Pruebas de Integración para Componentes de Software

INSTITUTO POLITCNICO NACIONAL
CENTRO DE INVESTIGACIN EN
COMPUTACIN
Laboratorio de Tecnologa de Software
Pruebas de integracin !ara
c"#!"nentes de s"$t%are
Tesis que para obtener el grado de
Doctor en Ciencias de la Computacin
presenta
Juan Manuel Fernnde !e"a
Director de tesis#
Dr$ %rbaro Jorge Ferro Castro
Maro de &''&
ii
Resu#en
(n los )ltimos a"os el desarrollo de software *a enfrentado presiones cada +e
ma,ores en cuanto a recursos , necesidades$ Dos elementos se +an fortaleciendo
para resol+er esta situacin# modelos de arquitectura de software- por el lado
terico , software basado en componentes .S%C/ como una solucin concreta-
basada en el reuso , la interoperabilidad de partes pree0istentes que se combinan
para formar aplicaciones$
(l software basado en componentes parece ser una buena alternati+a para
desarrollo de software comple1o- pero a condicin de contar con estndares , con
m2todos que aseguren la satisfaccin de requerimientos por parte del software$
(ste traba1o tiene como ob1eti+o establecer un procedimiento para proponer
m2todos de prueba de integracin- adecuados para una aplicacin basada en
componentes- empleando como gua su descripcin arquitectnica$
La *iptesis central que orienta el traba1o es que- dada su naturalea- las
descripciones arquitectnicas de software resultan una gua natural para la
preparacin de pruebas de integracin- especialmente en casos de software
comple1o como el basado en componentes$
(ste traba1o se limitar a la plataforma Ja+a &- uno de los estndares que estn
emergiendo$
(ntre los aportes que ofrece el traba1o se tienen#
a/ una e0tensin a 3ML que funciona como lengua1e descripti+o de
arquitectura orientado a software basado en componentes , que a,uda a
preparar las pruebas
b/ un modelo de defectos para el software basado en componentes- que
inclu,e no slo los posibles defectos- sino la relacin con sus causas
posibles , los problemas que originarn$
c/ modelado de S%C en forma combinatoria , de estados que permite analiar
di+ersas maneras de acoplamiento entre componentes$ 4 partir de este
modelado se preparan las pruebas$
d/ una propuesta de estrategia de prueba para software basado en
componentes- fundamentada tambi2n sobre la descripcin arquitectnica
de la aplicacin$
iii
Integrati"n Testing $"r s"$t%are c"#!"nents
Abstract
5n last ,ears- software de+elopment *ad confronted increasing pressures- on
resources and requirements$ Two elements- useful to sol+e t*is situation- *a+e
been strengt*ened# software arc*itecture models- in t*e t*eoretical side- and
component6based software .C%S/ de+elopment- as a concrete solution- oriented
toward interoperabilit, and reuse of pree0istent parts- w*ic* can be combined to
produce applications$
Component6based software seems to be a good wa, to de+elop comple0 software-
but onl, if t*ere are standards and met*ods to assure software requirements
satisfaction$
T*e ob1ecti+e of t*is wor7 is to establis* a procedure to propose integration testing
met*ods- adequate to component6based applications- using its arc*itectural
description as a guide$
Central *,pot*esis to inform t*is wor7 is t*e following# software arc*itecture
descriptions- b, its nature- is a natural guide to integration testing preparation- in
particular for comple0 software- li7e component6based software$
T*is wor7 would be limited to Ja+a & platform- one of t*e emerging standards$
Contributions from t*is wor7 includes#
a/ 4n 3ML e0tension- as an arc*itecture description language- oriented toward
component6based software- useful to test preparation
b/ 4 defect model for component6based software- w*ic* includes defects- its
relations*ip to possible causes- and potential problems t*at will surface after
t*em
c/ Combinatorial modeling of C%S t*at permit to anal,e se+eral
intercomponent coupling forms$ From t*is modeling tests would be prepared
d/ 4 testing strateg, for component6based software- also based on application
arc*itecture description
i+
Agradeci#ient"s
(ste traba1o se reali con el apo,o de di+ersas instituciones- a las que agradeco
la oportunidad de realiar el doctorado$ (llas son#
La Uni&ersidad Veracru'ana , en especial de la Facultad de (stadstica e
5nformtica- donde esto, adscrito- , de la Direccin se Superacin
4cad2mica$ (l apo,o inclu, beca por parte de la propia uni+ersidad , ms
tarde de PROMEP- con el n)mero 38(9 ''6':6'; .&<=/$
(l CONAC(T- que me apo, con la beca con n)mero de registro ;&=>;:$
(l Centr" de In&estigacin en C"#!utacin de) IPN- donde recib apo,o
desde mi ingreso$
4 mi asesor el Dr* +,rbar" -err" Castr" por su confiana- su apo,o , por sus
+aliosas orientaciones$
4 la Dra* .anna O/taba por sus detallada re+isin , sus +aliosas sugerencias$
4l Dr* Agust0n -* Guti1rre' T"rn1s por sus +aliosas sugerencias- especialmente
con relacin al Captulo <$
4l Dr* .ug" C1sar C"("te Estrada por sus sugerencias de enfoque del traba1o$
4l Dr* R"bert" Va)di&ia +eute)s!ac2er por sus cuestionamientos , sugerencias
4l Dr* Ad")$" Gu'#,n Arenas por su paciencia , amabilidad$
4l Dr* -e)i!e R")and" Menc2aca Garc0a por su paciencia , amabilidad$
+
Dedicat"ria
Dedico este traba1o a#
+i
C"ntenid"
AGRADECIMIENTOS..................IV
DEDICATORIA .................................V
CONTENIDO....................................VI
LISTA DE FIGURAS ..................XIII
LISTA DE TABLAS.....................XVI
INTRODUCCIN..............................1
MOTIVACIN.....................................1
OBJETIVOS.........................................3
METAS ESPECFICAS.........................4
ALCANCE ...........................................4
HIPTESIS..........................................5
APORTE..............................................5
BENEFICIOS.......................................6
ORGANIZACIN ................................7
CAPTULO 1 SOFTWARE BASADO EN
COMPONENTES..........................................................................8
1.1 PROBLEMTICA DEL DESARROLLO DE
SOFTWARE..........................................................................9
1.2 ARQUITECTURA DE
SOFTWARE...................................................................................................................11
1.2.1 CONCEPTOS BSICOS E AR!"ITECT"RA E SOFT#ARE
...............................................................................12
1.2.2 LENG"AJES ESCRIPTIVOS E AR!"ITECT"RA
$LA%...................................................................................14
1.2.2.1 Lenguajes especficos para descripcin arquitectnica.....................................................................16
Wrigth........................................17
C2...............................................19
ACM........................................2!
Co"paraciones........................22
1.2.2.2 nfoques "i#tos..........2$
Mode%ar caractersticas especficas de un %enguaje descripti&o de arquitectura en particu%ar' usando
e%e"entos de (ML...................2$
Modificaciones a (ML para representar conceptos de L)A ..........................................................................2$
*e%acin con prue+as. ............2,
1.3 NATURALEA DEL SOFTWARE BASADO EN
COMPONENTES ......................................................2!
1.3.1 CONCEPTO E COMPONEN&.25
)efiniciones genera%es -
tradiciona%es................................................................................................................2.
Conceptos %igados con %a orientacin a o+jetos................................................................................................26
Conceptos "odernos aca26
Conceptos "odernos co"2/
+ii
1.3.2 ANLISIS E LOS ELEMENTOS
COM"NES. .........................................................................................................2'
%e"entos co"unes a todas0 .29
%e"entos distinti&os..............29
1.3.3 APLICACIONES BASAAS EN
COMPONENTES....................................................................................................3(
1.3.4 ENFO!"ES AL EST"IO ) ESARROLLO E
COMPONENTES...........................................................................31
1." MODELOS DOMINANTES ..32
1.4.1 PLATAFORMA NA E MICROSOFT
.................................................................................................................33
1.,.1.1 1ecno%ogas que for"an %a p%atafor"a )2A.........................................................................................$,
1.,.1.2 Mode%o de co"ponente
C3M4................................................................................................................$.
Concepto de co"ponente.......$.
5nterfaces...................................$6
Creacin de instancias...........$7
*euti%i6acin.............................$7
7er&icios....................................$7
1.,.1.$ Arquitectura genera%
reco"endada ........................................................................................................$/
1.4.2 PLATAFORMA JAVA 2 E
S"N............................................................................................................................3*
1.,.2.1 1ecno%ogas que for"an %a p%atafor"a 8a&a 2 para e"presas..........................................................$9
1.,.2.2 Mode%os de co"ponentes
9:eans;...........................................................................................................,!
8a&a:eans.................................,!
nterprise 8a&a:eans 98:; .,2
(ti%i6acin de 8:...................,,
7er&%ets......................................,,
1.,.2.$ Arquitectura genera%
reco"endada ........................................................................................................,.
1.4.3 CORBA EL OMG. .............45
1.,.$.1 Arquitectura C3*:A.,6
Arquitectura de referencia.....,6
Co""on *equest :ro<er Architecture 9C3*:A;..............................................................................................,7
1.,.$.2 Mode%o de co"ponente
9propuesto; .......................................................................................................,7
1.4.4 COMPARACIN .....................4'
1.! RESUMEN...................................!#
CAPTULO 2 PRUEBAS DE INTEGRACIN DE SOFTWARE BASADO EN COMPONENTES ...!2
2.1 PRUEBAS DE SOFTWARE..!3
2.1.1 NECESIA E LA PR"EBA EL
SOFT#ARE. ....................................................................................................53
2.1.2 CONCEPTOS BSICOS............54
2.1.3 REALIZACIN E LAS P&SLIZA56
2.1.$.1 =reparacin .................7
2.1.$.2 jecucin......................7
2.1.$.$ 7uspensin....................7
2.$.1., strategias de prue+./
2.$.1.. 1a#ono"as de defe./
2.$.1.6 A#io"as de adecuacin de conjuntos de casos de prue+a .................................................................6!
2.1.4 NIVELES E PR"EBA. ...........61
=rue+as de integracin ..........62
2.1.5 PR"EBAS ) CALIA EL SOFT#ARE
................................................................................................................62
2.1.6 CALIA E LAS PR"EBAS..63
2.2 PRUEBA DE SOFTWARE ORIENTADO A
OB$ETOS..............................................................................%"
2.2.1 ESARROLLO ORIENTAO A OBJETOS )
PR"EBAS...........................................................................................64
2.2.2 !"+ HACE IFERENTE AL SOFT#ARE
OO.........................................................................................................65
2.2.3 PR"EBAS E INTEGRACIN EN
SOO..................................................................................................................6*
=rue+as de unidad ..................6/
=rue+as de siste"a..................6/
+iii
=rue+as de integracin ..........6/
M>todo de ca"inos MM.........69
M>todo de 3&er+ec<...............69
M>todo de ?ung - sus
co%a+oradores..................................................................................................................7!
M>todo propuesto por :ashir -
@oe%...................................................................................................................7!
=ropuesta de :inder ...............72
C%ienteAser&idor.......................7$
7er&icios distri+uidos.............7,
2.2.4 SIT"ACIN ACT"AL. ............74
2.3 PRUEBAS DE SOFTWARE BASADO EN
COMPONENTES ...................................................................&!
2.3.1 NECESIAES E PR"EBA E
COMPONENTES. .................................................................................................75
2.$.1.1 )iferencias i"porta7.
2.$.1.2 2ecesidades en diferentes etapas de% cic%o de &ida .............................................................................7/
tapa de desarro%%o de%
co"ponente. ..................................................................................................................7/
tapa de se%eccin - e&a%uacin de co"ponentes.............................................................................................7/
tapa de integracin de
co"ponentes.................................................................................................................79
2.$.1.$ =rue+as por ni&e%......./!
2.3.2 PR"EBAS E "NIA ...........*(
Certificacin de co"ponentes 8a&a
:eans. ......................................................................................................../1
1rusted Co"ponents.............../1
=rue+a por terceros................/2
2.3.3 PR"EBAS E INTEGRACIN.*3
2.$.$.1 Caractersticas de %as prue+as de integracin...................................................................................../$
*e%acin con %a arquitectura./$
Mode%ado de co"posicin - criterios de adecuacin ......................................................................................./,
Condiciones "ni"as............../.
Mo"entos de ap%icar%as........./6
2.$.$.2 #periencias repor/7
(na e#periencia pro+%e"Bti/7
M>todo sugerido por Coas.....//
2." RESUMEN...................................89
CAPTULO 3 MODELADO DE SOFTWARE BASADO EN
COMPONENTES......................................9#
3.1 DEFINICIONES ........................91
3.1.1 COMPONENTE .......................'1
3.1.2 CONECTOR.............................'1
3.1.3 APLICACIN $APLICACIN E SOFT#ARE BASAO EN
COMPONENTES% .......................................................'1
3.1.4 CONTENEOR........................'2
3.1.5 PLATAFORMA........................'2
3.1.6 SOFT#ARE INTERMEIO......'2
3.2 UNA DESCRIPCIN ARQUITECTNICA PARA EL
SBC......................................................................92
3.2.1 NECESIA E "N LA ......'2
3.2.2 CARACTERSTICAS !"E EBE
SATISFACER.......................................................................................................'3
3.2.3 ALTERNATIVAS E SOL"&NAT'4
3.3 ARQUIPP ....................................9%
3.3.1. ESCRIPCIN .......................'6
3.3.2. E,TENSIONES NECESARIAS COMO
PRERRE!"ISITOS......................................................................................'6
3.3.3. ESTEREOTIPOS.....................'7
3.3.4. REGLAS E CONSTR"C&POS.1(1
3.3.5. COMENTARIOS.................. 1(1
3.3.6 ELEMENTOS AICIONALES !"E SE
MOIFICAN............................................................................................. 1(2
i0
3.". USO DE ELEMENTOS DE
ARQUIPP ...........................................................................................................1#3
3.4.1 MOELAO E TIPOS E INSTANCIAS E
COMPONENTES.............................................................................. 1(3
)iagra"a estBtico.................1!,
3.4.2 MOELAO E P"ERTOS.. 1(4
3.4.3. LNEA ................................. 1(5
3.4.4 MOELAO E CONEC&O...1(6
5nteracciones asociadas con un conector.........................................................................................................1!6
Concatenacin de
conectores. ............................................................................................................................1!7
3.4.5 MOELAO E ENLACES.. 1(*
3.4.6. IAGRAMA TOPOLGICO 11(
3.4.7. CASO E "SO..................... 111
3.4.* INTERACCIN ..................... 112
3.4.' IAGRAMA E ESPLIE&...115
3.4.1( ESCRIPCIN E APLICACIONES CON
AR!"IPP.......................................................................................... 116
3.! COMPONENTES EN LA PLATAFORMA $AVA
2 ....................................................................................11%
3.5.1 ELEMENTOS A CONSIE&S..117
3.5.2 REPRESENTACIN E ELEMENTOS E JAVA 2 CON AR!"IPP .....................................................................
11'
$...2.1 Co"ponentes.............119
App%ets.....................................12!
8a&a:eans...............................12!
$...2.2 Conectores.................121
&entos....................................121
3.% APLICACIN DE E$E12"
3.6.1. LA APLICACIN AMECALIF
.......................................................................................................................... 124
3.6.2. CASOS E "SO................... 125
3.6.3. AR!"ITECT"RA PROP&TECT"125
3.6.4. COMPONENTES ) &OMPONENTES126
3.6.5. INTERACCIONES................ 12*
3.6.6 PERFIL ................................. 131
3.& RESUMEN.................................131
CAPTULO " TAXONOMA DE DEFECTOS DE SOFTWARE BASADO EN COMPONENTES .133
".1 PROBLEMAS CON EL
SOFTWARE..............................................................................................................13"
".2 'IPTESIS ESPECFICAS 13!
4.2.1 PROBLEMAS EN LOS
COMPONENTES............................................................................................................... 136
,.2.1.1 ncapsu%a"iento......1$6
,.2.1.2 *euti%i6acin .............1$7
,.2.1.$ Derencia ....................1$7
,.2.1., Adaptacin de%
co"ponente...................................................................................................................1$/
,.2.1.. 5ntrospeccin ............1$/
,.2.1.6 )ocu"entacin.........1$/
4.2.2 A SPECTOS E INTERACCIN
............................................................................................................................ 13*
,.2.2.1 7e%eccin dinB"ica..1$9
,.2.2.2 Conector....................1$9
,.2.2.$ =rotoco%o ...................1$9
,.2.2., )istri+ucin ..............1$9
,.2.2.. Co"ponentes 1,!
,.2.2.6 Concurrencia............1,!
4.2.3 PROCESO E ESARROLL&-14(
4.2.4 PLATAFORMA JAVA 2........ 14(
0
4.2.5 FALLAS EN EL AMBIENTE . 141
".3 CICLO DE VIDA DE
DEFECTOS....................................................................................................................1"1
4.3.1 FALLAS OBSERVABLES...... 142
,.$.1.1 1ipos de fa%%a ............1,$
,.$.1.2 Loca%i6acin de %a 1,.
,.$.1.$ Consecuencias..........1,.
4.3.2 EFECTOS EN LA APL&CTOS./-146
,.$.2.1 1ipos de defectos......1,7
,.$.2.2 Loca%i6acin..............1,9
,.$.2.$ Mo"ento de
in-eccin ............................................................................................................................1.2
Cic%o de &ida de softEare +asado en co"ponentes.........................................................................................1.2
Mo"entos de posi+%e in-1.$
4.3.3 E!"IVOCACIN H"MANA E
INTENCIONALIA............................................................................................ 154
"." RESULTADOS ( CMO
USARLOS ..............................................................................................................1!%
4.4.1 A SOCIACIN E RES&ACIN..156
4.4.2 EFECTOS POR NIVEL E
PR"EBA................................................................................................................... 15*
4.4.3 "TILIZACIN E RES&IZACIN16(
".! RESUMEN.................................1%#
CAPTULO ! CASOS DE PRUEBA DE
INTEGRACIN............................................................................1%2
!.1 M)TODOS DE VERIFICACIN A PARTIR DE LA
ARQUITECTURA...........................................1%3
5.1.1 EFINICIONES.................... 163
5.1.2 CONECTIVIA COMPLE&VI164
5.1.3 COMPATIBILIA E
COMPONENTES.............................................................................................................. 164
CONECTORES................................................................................................................. 165
INTERACCIONES............................................................................................................ 165
5.1.6 AVISOS E CONC"RRENCIA
............................................................................................................................. 165
!.2 FORMAS DE ACOPLAMIENTO ENTRE
COMPONENTES .................................................................1%%
5.2.1 ACOPLAMIENTO................. 166
5.2.2 CONSIERACIONES ACERCA EL ESTAO
..................................................................................................... 16*
5.2.3 CONSIERACIONES ACERCA E LA
CONC"RRENCIA.................................................................................... 17(
!.3 GENERACIN DE DOMINIOS ( ESTADOS A PARTIR DE
ESCENARIOS ..................................1&1
5.3.1 GENERACIN E OMINI&I171
5.3.2 GENERACIN E ESTAO&I173
!." M)TODO COMBINATORIO
BSICO ..........................................................................................................1&"
5.4.1 PARTE GENERAL................ 174
5.4.2 E,TENSIN PARA CONSIERAR ESTAO
........................................................................................................ 176
5.4.3 E,TENSIN A N CO&ENSIN...176
!.! CONVERSIN DE OTRAS FORMAS DE
ACOPLAMIENTO...............................................................1&8
5.5.1 AGREGACIN SIMPLE )
M0LTIPLE.................................................................................................................. 17*
5.5.2 AGREGACIN RAMIFICA&N.17*
....2.1 7epara+%e...................179
....2.2 (nidas........................179
....2.$ Co"puestas...............1/!
....2., 7i"u%tBneas...............1/!
5.5.3 AGREGACIN CON CICLOS 1*(
5.5.4 AGREGACIN CONC"&CIN1.1*1
5.5.5 A SOCIACIN ASNCRONA. 1*1
0i
!.% CASOS DE PRUEBA.............182
5.6.1 S"BOMINIOS ATRAVIESA )
RELEVANTE...................................................................................................... 1*2
5.6.2 CRITERIO PARA ETERMINAR S"BOMINIOS E
INTER+S........................................................................... 1*2
5.7.3 GENERACIN E CASOS E
PR"EBA............................................................................................................... 1*3
!.& CASOS PENDIENTES ..........18"
!.8 PRUEBAS NO
FUNCIONALES .........................................................................................................................18"
5.*.1 ROB"STEZ .......................... 1*5
5.*.2 MANEJO E E,CEPCIONES 1*5
5.*.3 FALLAS E "N COMPONENTE O "N
CONECTOR............................................................................................. 1*5
5.*.4 FALLAS E HAR#ARE ) RE
......................................................................................................................... 1*6
!.9 RESUMEN.................................18&
CAPTULO % ESTRATEGIA DE PRUEBA DE
INTEGRACIN..............................................................189
%.1 CONSIDERACIONES
GENERALES ..............................................................................................................19#
6.1.1 CONE,IN CON LOS MOELOS AR!"ITECTNICO ) E
EFECTOS............................................................ 1'(
6.1.2 C"NO APLICAR PR"EBAS E
INTEGRACIN.............................................................................................. 1'(
6.1.3 CONICIONES ESPECIALES EL
SBC............................................................................................................... 1'1
6.1.4 CRITERIOS........................... 1'2
%.2 ESTRATEGIA GENERAL..193
%.3 VERIFICACIN
ESTTICA .............................................................................................................................19"
6.3.1 REVISIN AR!"ITECT&....1'5
6.3.2 ELEMENTOS ESPROT&S....1'5
6.3.3 F"NCIONES FALTANTES O
SOBRANTES........................................................................................................... 1'6
6.3.4 BASES EN EL MOELO E
EFECTOS.............................................................................................................. 1'6
%." PRUEBAS DE OPE19%
%.! PRUEBAS DE
INTEROPERACIN ................................................................................................................198
6.5.1 PR"EBAS F"NCIONALES.... 1''
6.5.2 ROB"STEZ .......................... 2((
6.5.3 PR"EBAS E CONC"RRENCIA
.......................................................................................................................... 2(1
6...$.1 Concurrencia i"p%2!2
6...$.2 Concurrencia e#p%2!2
6.5.4 CONE,IN CON EL MOELO E
EFECTOS.................................................................................................... 2(2
%.% OTRAS PRUEBAS .................2#3
6.6.1 CARGA................................. 2(3
%.& PROCEDIMIENTOS
RESULTANTES ...........................................................................................................2#"
6.7.1 PARTE I2 VERIFICACIN
TOPOLGICA............................................................................................................ 2(4
6.7.2 PARTE II2 ANLISIS............ 2(4
6.7.3 PARTE III2 SNTESIS........... 2(5
6.7.4 "SO EL PROCEIMIENTO 2(6
6.7.,.1 7iste"a de consu%ta de ca%ificaciones 5................................................................................................2!6
6.7.,.2 AnB%isis de ap%icacin de eje"p%o de% Captu%o $..............................................................................2!/
%.8 RESUMEN.................................211
REFERENCIAS
BIBLIOGRFICAS .....................................................................................................................21%
0ii
AP)NDICE A..................................22&
MODELADO DE ELEMENTOS DE LA PLATAFORMA $AVA 2 USANDO ARQUIPP.....................22&
A.1. COMPONENTES..................228
A.1.1 APPLETS............................. 22*
A.1.2 JAVABEANS. ...................... 22'
A.1.3 OBJETO REMOTO............... 23(
A.1.4 SERVLETS........................... 232
A.1.5 ENTERPRISE JAVABEAN.. 232
A.1.6 ARCHIVO SIMPLE.............. 235
A.1.7 #EB BRO#SER.................. 235
A.1.* BASE E ATOS................. 236
A.1.' SERVIOR E,TERNO......... 237
A.2. CONECTORES .....................238
A.2.1 EVENTOS............................ 23*
A.2.2 HTTP................................... 24(
A.2.3 CON&SERVLET .................. 242
A.2.4 RMI ..................................... 243
A.2.5 CONECTOR EJB................. 246
A.2.6 STREAM ............................. 247
A.2.7 JBC3OBC........................ 24*
A.2.* SOC4ET .............................. 25(
0iii
Lista de -iguras
Figura ;$;$ (1emplo de diagrama arquitectnico- correspondiente a Ja+a &
.adaptado de ?S3@-
;:::A/$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$;>
Figura ;$&$ 8ersin alternati+a de figura
;$; $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$;>
Figura ;$<$ Sistema cliente
ser+idor$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$;=
Figura ;$B$ Descripcin de cliente ser+idor en
Crigt*$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$;:
Figura ;$> e1emplo de estructura de sistema en
C&$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$&'
Figura ;$D (1emplo en C&S4D(L .adaptado de ?Med+ido+ic et al-
;:::A $$$$$$$$$$$$$$$$&;
Figura ;$E Ciclo de +ida de
S%C $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$<;
Figura ;$= 4rquitectura de tres
ni+eles$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$<<
Figura ;$:$ 5nterfa en CFM .adaptada de ?Gra,-
;::=A/$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$<D
Figura ;$;' Funcionamiento de una
ser+let$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$B>
Figura ;$;; 4rquitectura tpica de sistema basado en
(J%$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$B>
Figura ;$;&$ 4rquitectura de referencia .adaptada de ?!ope-
;::=A/$$$$$$$$$$$$$$$$$$$$$$$$BE
Figura &$;$ 9elacin entre (specificacin e
5mplementacin$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$><
Figura &$&$ 9elacin entre (specificacin- 5mplementacin ,
!rueba$$$$$$$$$$$$$$$$$$$$$$DB
Figura &$< Matrices de uso , de
colaboracin$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$E;
Figura <$;$ (0tensin propuesta por ni+el de
modelado$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$:E
Figura <$& 5cono de
puerto$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$:=
Figura <$< 5cono de
componente $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$::
Figura <$B$ 5conos de
conector$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;';
Figura <$> Componente con sus
partes $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;'B
Figura <$D !uerto con sus
partes$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;'>
Figura <$E$
Lnea $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;'>
Figura <$= Modelado de un
conector $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;'D
Figura <$: Concatenacin de
conectores$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;'E
Figura <$;'$ Combinacin de interacciones en conector concatenado$ $$$$$$$$$$$$$$$$
;'=
Figura <$;;a (structuras de
(nlace$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;':
Figura <$;;b (structuras de
(nlace$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;':
Figura <$;& Diagrama
topolgico $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;;'
Figura <$;< Segmento de diagrama topolgico indicando multiplicidad$$$$$$$$$$$$$$$$
;;'
Figura <$;B Diagrama topolgico , sus partes$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;;;
Figura <$;> Caso de uso , sus
partes $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;;&
Figura <$;D Clasificador para interacciones entre lneas $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;;B
Figura <$;E Diagrama de secuencia con sus partes $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;;B
Figura <$;= Diagrama de
despliegue$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;;D
Figura <$;:$ (structura de un
4pplet$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&'
Figura <$&'$ Modelado de aspectos bsicos de Ja+a%eans$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&;
Figura <$&;$ Modelado del conector
(+ento $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&&
0i+
Figura <$&&$ Cone0in de Ja+a%eans usando (+ento$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&&
Figura <$&<$ Diagrama de estados de la interaccin de (+ento$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&<
Figura <$&B$ Diagrama de secuencia para conector de e+entos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&B
Figura <$&> Caso de uso de la aplicacin Damecalif$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&>
Figura <$&D Salida esperada a una
consulta $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&>
Figura <$&E Salida en caso de error en nombre o contrase"a $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&>
Figura <$&= Diagrama topolgico de Damecalif$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&D
Figura <$&: Diagrama de despliegue de Damecalif$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&D
Figura <$<' Componente
Consulta $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&E
Figura <$<; Componente
4ccesoHbd $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&E
Figura <$<& Componente %ase de
datos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&=
Figura <$<< 5nteraccin de registro de 4ccesoHbd$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;&=
Figura <$ !roblema con
4ccesoHbd $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&:
Figura <$<D !roblema en %ase de
datos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;<'
Figura <$<E (rror en identificacin de usuario$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;<'
Figura <$<= Consulta
e0itosa$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;<;
Figura B$; !roblemas de
interaccin $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;<>
Figura B$& !artes de un
componente$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;>'
Figura B$< 3sos del modelo de
defectos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;D'
Figura >$; 9elacin de
agregacin $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;DE
Figura >$& 4gregacin entre ms de dos componentes $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;DE
Figura >$< !artes de un
componente$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;E&
Figura >$B Subdominios rele+antes en la interaccin entre componentes$ $$$$$$$$$$$
;E>
Figura >$> (stado como parte de la entrada$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;EE
Figura >$D Caso de tres
componentes$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;EE
Figura >$E 4gregacin
ramificada $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;E:
Figura >$= 9esultado de combinar % , C para ramificacin unida$$$$$$$$$$$$$$$$$$$$$$$$$$
;E:
Figura >$: 4coplamiento con
ciclos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;='
Figura >$;' 9uptura de
ciclo $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;='
Figura >$;; 4gregacin
concurrente $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;=;
Figura >$;& Comunicacin con
fallas$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;=D
Figura D$; (1emplo de
despliegue$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;:=
Figura D$& Casos de uso de la
aplicacin $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &'D
Figura D$< Diagrama topolgico de la aplicacin$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&'E
Figura D$B Diagrama de despliegue de la aplicacin $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&'=
Figura 4$;$ (structura de un
4pplet$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &&:
Figura 4$&$ Modelado de aspectos bsicos de Ja+a%eans$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&&:
Figura 4$< !uerto para introspeccin en Ja+a%eans $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&<'
Figura 4$B !uerto de e+entos en Ja+a%eans $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&<'
Figura 4$>$ Fb1eto
remoto$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<;
Figura 4$D !uerto de cone0in
9M5$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<;
Figura 4$E !uerto de comunicacin para ob1eto remoto $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&<&
Figura 4$= (structura de
ser+let $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<&
Figura 4$: (structura bsica de un
(J% $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<<
Figura 4$;' !uerto de cone0in
(J%$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<B
Figura 4$;; !uerto de comunicacin con (J%$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&
Figura 4$;<$ (structura de un web browser$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&<D
Figura 4$;B %ase de
datos $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<D
Figura 4$;> (structura de ser+idor
e0terno $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<E
Figura 4$;D !uertos de ser+idor
e0terno$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<E
Figura 4$;E$ Modelado del conector (+ento$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&<:
Figura 4$;=$ Diagrama de secuencia para conector de e+entos$ $$$$$$$$$$$$$$$$$$$$$$$$$$$
&<:
Figura 4$;:$ Diagrama de estados de la interaccin de (+ento $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B'
Figura 4$&' (structura del conector
*ttp $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &B;
Figura 4$&; !uerto
p*ttp $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &B;
Figura 4$&& 5nteraccin del conector
*ttp$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &B&
Figura 4$&< (structura del conector conHser+let$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B&
Figura 4$&B !uerto
pser+let$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &B<
Figura 4$&> 5nteraccin del conector conHser+let$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B<
Figura 4$&D (nlaces del conector 9M5$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&BB
Figura 4$&E (structura del conector 9M5$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B>
Figura 4$&= 5nteraccin de
control$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &B>
Figura 4$&: 5nteraccin de comunicacin$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&BD
Figura 4$<' 5nteraccin de ser+icio del conector Con(1b $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&BD
Figura 4$<; 5nteraccin entre cliente , (J%$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&BE
Figura 4$<& (structura del conector Stream$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&BE
Figura 4$<< 5nteraccin en conector Stream $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B=
Figura 4$ !uerto de control del conector 1dbc6odbc$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B:
Figura 4$<D 5nteraccin de cone0in en el conector 1dbc6odbc$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&B:
Figura 4$<E 5nteraccin de uso de base de datso en 1dbc6odbc $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&>'
Figura 4$<= (structura del conector Soc7et $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&>;
Figura 4$<: 5nteraccin de comunicacin en Soc7et$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&>;
0+i
Lista de Tab)as
Tabla ;$; Comparacin de plataformas
dominantes$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$B:
Tabla &$;$ Ta0onoma de !urc*ase ,
Cinder$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$>:
Tabla &$&$ Ta0onoma de
Firesmit*$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$>:
Tabla &$<$ Ta0onoma de Landwe*r et
al$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$>:
Tabla &$B$ Gra+edad de fallas- seg)n
%eier$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$D'
Tabla &$>$ Caractersticas del S%C que influ,en en
pruebas$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ED
Tabla <$; Caractersticas satisfec*as por cada elemento considerado$$$$$$$$$$$$$$$$$
;;=
Tabla <$&$ Tipos de
componente $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;;:
Tabla <$<$ Tipos de
conector$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;&;
Tabla B$; !roblemas de
interaccin$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;<D
Tabla B$& Tipos de
falla $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;B<
Tabla B$< Fallas de acuerdo a sus consecuencias$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;BD
Tabla B$B Tipos de
defectos $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;BE
Tabla B$> Localiacin de
defectos$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;>;
Tabla B$D Defectos de acuerdo al momento de in,eccin$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;><
Tabla B$E$ (qui+ocaciones e intencin de acuerdo al origen$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;>>
Tabla B$= 4sociaciones origen6defecto6falla $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;>D
Tabla B$: Defectos seg)n ni+eles de pruebas$ $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;>:
Tabla >$; Diferentes formas de acoplamiento entre componentes $$$$$$$$$$$$$$$$$$$$$$$$
;D=
Tabla D$; (strategia
general $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ;:B
Tabla D$& 9elacin entre el modelo de defectos , la +erificacin esttica $$$$$$$$$$$$
;:E
Tabla D$< Cone0iones entre el modelo de defectos , pruebas operacionales $$$$$
;::
Tabla D$B Cone0in entre pruebas de interoperacin , modelo de defectos$$$$$$$$
&'<
Tabla D$> 4nlisis de
conectores$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &'=
Tabla D$D 4nlisis !arte
5$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &':
Tabla D$E (lementos arquitectnicos# componentes$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&':
Tabla D$= (lementos arquitectnicos# pare1as$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&':
Tabla D$:
5nteracciones $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &;'
Tabla D$;' 9esumen de dominios , estados $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
&;'
Tabla 4$;$ Tipos de
componente $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &&=
Tabla 4$&$ Tipos de
conector $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ &<=
;
Intr"duccin
(l traba1o doctoral que aqu se reporta tiene como propsito preparar pruebas de
integracin para software basado en componentes- a partir de elementos de
arquitectura de software$ (n su desarrollo el pro,ecto gener un lengua1e de
modelado arquitectnico- un modelo de defectos- anlisis de acoplamiento entre
componentes , un procedimiento para proponer pruebas de integracin$
4 continuacin se describen la moti+acin- los propsitos , aportes especficos ,
la organiacin del traba1o$
Motivacin
(l desarrollo de software +a pasando poco a poco de un proceso lnea por lnea-
de modo casi artesanal- a otro de ensamble de unidades preconstruidas- llamadas
gen2ricamente componentes .?C*apell- ;::EA- ?8oas- ;::= aA/$ La idea de emplear
elementos pree0istentes no es nue+aI el propio t2rmino componente se *a
empleado por +arias d2cadas para referirse a elementos reutiliables$ Sin
embargo- el 2nfasis actual tiende a la reutiliacin masi+a de elementos- en forma
comercial- como se *ace en di+ersas ramas de la ingeniera$
Desde *ace tiempo se *abla de construir software como se constru,en artefactos
electrnicos- uniendo pieas estndar$ Sin embargo- *asta *ace poco- el costo lo
*aca poco atracti+o$ Jaca falta una moti+acin que lo 1ustificara- como la
comple1idad del software distribuido- a ni+el de empresa$
&
(n la actualidad- el software de empresa se *a tornado cada +e ms comple1o-
debiendo resistir cambios frecuentes en su plataforma de *ardware , a)n en el
software- adaptndose a sistemas distribuidos , con un uso creciente de sistemas
que descansan en 5nternet$ 4l mismo tiempo- para muc*os pro,ectos- aumentan
las presiones para reducir costos , tiempos de desarrollo$
Tales presiones , tendencias en la industria del software *an obligado a buscar
soluciones que no brindan los m2todos tradicionales de desarrollo de software$
4lgunos esfueros *an sido de tipo terico- como el modelado arquitectnico- que
busca mane1ar la comple1idad creciente a tra+2s de abstracciones que faciliten
raonar acerca de un sistema$ (l desarrollo del concepto de arquitectura de
software *a crecido especialmente a partir de los traba1os de ?S*aw , Garlan-
;::DA$
Ftros esfueros son de tipo prctico- que lle+an al reuso de elementos
pree0istentes- que +an desde peque"os elementos .funciones o clases/- a
mdulos o aplicaciones enteras$ (stos elementos prcticos usan nombres como
software plug and play- components of the shelf , otros seme1antes$ (n t2rminos
generales se le puede llamar software basado en componentes$
(ntre el software basado en componentes se puede distinguir aquel que
representa una tendencia particular de reuso organiado , no de un simple intento
de pegar elementos$ (stos esfueros especiales se concentran alrededor de
software intermedio que brinda un marco de traba1o co*erente$ !or el momento
e0isten tres corrientes principales# la representada por la plataforma CF9%4- la
plataforma D@4 de Microsoft , la plataforma Ja+a & de S3@ Micros,stems$
(l software basado en componentes gira en torno al concepto de componente$
Desgraciadamente a)n no e0iste una definicin generalmente aceptada- aunque
cualquier definicin debe incluir los elementos siguientes#
3n componente de software es una unidad encapsulada que#
o se despliega independientemente;
o ofrece interfaces bien definidas
o requiere ser+icios a tra+2s de otras interfaces bien definidas
o est dise"ado para combinarse con otros componentes$
3na aplicacin de software basado en componentes es un con1unto de
componentes ensamblados para traba1ar 1untos$ (n muc*os casos corresponder
a software desarrollado en +arios ni+eles , su acti+idad estar coordinada por las
funciones in+ocadas por un ser *umano a tra+2s de la interfa con el usuario$ 3n
; 3tiliamos KdesplegarL como traduccin de Kto deplo,L- para referirnos a la instalacin de una
piea de software en un equipo especfico donde se e1ecutar$ Despliegue independiente significa
que la piea de software puede ser instalada sin la presencia de otras con las que guardar
relacin- tal como una biblioteca o un arc*i+o de datos$
<
componente puede estar formado por componentes menores , a +eces una
aplicacin puede comportarse como un componente de algo ma,or$
De contarse con software basado en componentes- se obtendran di+ersos
beneficios- como una ma,or rapide de desarrollo .?%erg- ;::EA- ?Me,er- ;:::A/-
reduccin de costos proporcional al grado de reuso de un componente ?8oas et al-
;::E bA- reduccin de comple1idad al encapsular partes de la aplicacin-
alternati+as de implementacin de diferentes pro+eedores- mantenimiento
simplificado , e+olucin continua al permitir un reemplao rpido de elementos con
+ersiones nue+as$
(stas +enta1as suponen que e0ista un mercado de componentes , que estos
puedan interoperar$ !ara que esto sea realidad deben e0istir estndares que
aseguren cierta interoperabilidad- , tambi2n debe poder comprobarse que un
componente satisface los requerimientos del desarrollador$ (l primer punto- los
estndares- estn siendo concretados por las plataformas mencionadas
anteriormente$ !ara el otro punto *a, poco traba1o en desarrollo$
(n relacin con el aseguramiento de los componentes- puede mencionarse lo
siguiente#
o Las plataformas mencionadas- *an dado gran importancia a las interfaces
que ofrecen los componentes$ Sin embargo- estas interfaces estn
definidas )nicamente a ni+el sintctico$ (sta situacin permite la confusin
de funciones , parmetros- abriendo muc*as posibilidades de problemas en
la interaccin entre componentes$
o Se *a establecido- tanto terica como prcticamente- que los componentes-
a)n probados indi+idualmente- pueden causar problemas al interactuar en
una aplicacin particular .?8oas et al- ;::E bA- ?Ce,u7er- ;::=A/$ (sto puede
ocasionar problemas al desarrollador- inclusi+e de tipo legal- ,a que ser
2ste quien presente el producto final$
!uede resumirse la situacin as# el software basado en componentes .S%C/ es
una opcin para generar software de empresa que parece +a ganando terreno- a
pesar de no estar completamente definido- pero que necesita estndares ,
m2todos de prueba que aseguren el funcionamiento de componentes , de
aplicaciones$ 4dicionalmente se puede decir que los esfueros de modelado
arquitectnico son un elemento necesario para la descripcin del S%C$
Objetivos
4nte la creciente importancia del uso de componentes , de la carencia de
m2todos establecidos para prueba de integracin de aquellos en aplicaciones
particulares- se propone como ob1eti+o general de este traba1o el siguiente#
(stablecer un procedimiento para proponer m2todos de prueba de
integracin adecuados para una aplicacin basada en componentes-
empleando como gua su descripcin arquitectnica
B
!ara *acer realidad este ob1eti+o se plantean los siguientes ob1eti+os particulares#
5/ Determinar una manera de modelar software basado en
componentes de tal forma que los modelos puedan usarse en la
deri+acin de pruebas de integracin$
55/ Contar con un marco de referencia acerca de los posibles
problemas de integracin de componentes en aplicaciones$
555/ Contar con un procedimiento para asegurar que un componente
cumple las funciones que se esperan de 2l , no genera
problemas al resto de la aplicacin$
58/ Contribuir al establecimiento de procesos de aseguramiento de
calidad del software basado en componentes en lo referente a
pruebas$
De estos ob1eti+os- los tres primeros son los ms importantes , particulares para
este traba1o- mientras el )ltimo resulta un poco ms general , sir+e para situar el
pro,ecto en un conte0to ms amplio$
Metas especficas.
!ara el logro de los ob1eti+os- este traba1o se propone las metas siguientes- que
muestran cmo se pretende alcanar el propsito#
;$ !roponer un lengua1e descripti+o de arquitectura orientado a
software basado en componentes , )til para pruebas$
&$ !roponer un modelo de defectos para el software basado en
componentes$
<$ (stablecer un m2todo para deri+ar pruebas de integracin
especficas a partir de la descripcin arquitectnica de una
aplicacin dada$ Las pruebas estarn fundadas sobre el modelo de
defectos$
B$ !roponer una estrategia de prueba- con base en la descripcin
arquitectnica , la naturalea del S%C$ La estrategia re)ne las
sugerencias de la meta anterior$
(n forma au0iliar- dado el estado de +aguedad del concepto de software basado
en componentes- se deber#
>$ (stablecer caractersticas bsicas que debe satisfacer un
componente$ La lista debe ser de utilidad en la planeacin de
pruebas$
Alcance
(l traba1o- por la falta de desarrollo del S%C , por el enfoque arquitectnico que se
le dio- cubre muc*os aspectos- gran parte de los cuales a)n estn por
establecerse- como los relati+os a arquitectura$ !or otra parte- las diferentes
>
plataformas e0istentes- a)n cuando tienden a con+erger- difieren en gran n)mero
de detalles$ 4s pues- se *ace necesario limitar el alcance del traba1o- como sigue#
a/ (n relacin con la arquitectura de software- slo se desarrollarn elementos
necesarios para el propsito de generar pruebas de integracin- sin
a*ondar en ese campo tan amplio , prometedor$
b/ (n cuanto a plataforma- el traba1o se referir principalmente a la !lataforma
Ja+a &- que tiene a su fa+or su creciente difusin , su independencia de un
equipo , sistema operati+o especficos , que +a ganado apo,o de mu,
di+ersas empresas$ Sin embargo- muc*os elementos sern transferibles a
otras plataformas$
c/ (l traba1o no inclu,e la generacin de casos de prueba especficos- ,a que
e0isten problemas para determinar las especificaciones concretas de cada
componente en materia de parmetros$
d/ !or el momento se de1arn de lado algunos aspectos relacionados con la
concurrencia entre componentes- ,a que es un rea que merece otro
traba1o por s sola$
Hiptesis
(l traba1o descansa sobre una *iptesis fundamental#
Las descripciones arquitectnicas de software- por su naturalea estructural
, por enfatiar la interaccin entre partes- resultan una buena gua para la
preparacin de pruebas de integracin- especialmente en casos de software
comple1o como el basado en componentes$
4dems se *an *ec*o una serie de suposiciones que se presentaron en di+ersos
puntos- pero que con+iene precisar#
a/ (l software basado en componentes .S%C/ es una tendencia en desarrollo
de software que se est consolidando$
b/ La naturalea del S%C es diferente al tradicional- especialmente por su
encapsulamiento estricto , falta de acceso al cdigo fuente$
c/ (l S%C requiere una descripcin arquitectnica- ms all de la tradicional
de mdulos , llamadas$
d/ Las pruebas son un elemento necesario para comprobar el cumplimiento de
los requerimientos , contribuir a asegurar la calidad del mismo$
La primera suposicin se relaciona con la con+eniencia del tema propuesto en
general$ Las otras tres 1ustifican el trato particular que se dar a las pruebas de
integracin del S%C$
Aporte
Di+ersos autores reconocen la necesidad de aplicar pruebas especficas al
software basado en componentes$ Sin embargo *a, pocos esfueros orientados
en esa direccin$
D
4s mismo- los autores que traba1an sobre arquitectura de software *an
mencionado su posible utilidad en la preparacin de pruebas- pero no se *a
a+anado muc*o en esa direccin$
4s- los aportes principales de este traba1o son#
e/ Ar3ui!!- una e0tensin a 3ML que constitu,e un lengua1e descripti+o de
arquitectura orientado a software basado en componentes , que a,uda a
preparar las pruebas$ (sta e0tensin modela el S%C desde un punto de
+ista arquitectnico pero ligado a su implementacinI inclu,e una +ista
topolgica .en sentido diferente al de 3ML/ que permite un anlisis con1unto
de la aplicacin$ (sta e0tensin es original , se presenta en el Captulo <$
f/ 3n modelo de defectos para el software basado en componentes- que
inclu,e no slo los posibles defectos- sino la relacin con sus causas , los
problemas que originarn$ Tal modelo no e0iste en la literatura consultada
,- a)n en software tradicional donde s *a, resultados- no es un asunto
cerrado$ (ste modelo de defectos sir+e de base a la preparacin de
pruebas , adems a,uda a pre+enir defectos , depurar el software de
componentes$ (ste modelo se presenta en el Captulo B$
g/ Modelado de S%C en forma combinatoria , de estados que permite analiar
di+ersas maneras de acoplamiento entre componentes$ 4 partir de este
modelado se preparan las pruebas$ 4 pesar de emplear elementos
e0istentes- en su con1unto los m2todos propuestos son originales$ Se
presenta en el Captulo >$
*/ 3na propuesta de estrategia de prueba para software basado en
componentes- fundamentada tambi2n sobre la descripcin arquitectnica
de la aplicacin$ La estrategia se concreta en un procedimiento para deri+ar
pruebas$ (sta estrategia es original , se presenta en el Captulo D$
4dicionalmente- el desarrollo del traba1o obliga a profundiar acerca de los
conceptos relacionados con componentes , arquitectura de software- lo que
sentar bases para pro,ectos futuros$ (stos aspectos aparecen en di+ersas partes
del traba1o- principalmente en los Captulos ; , <$
Beneficios
4lgunos de los beneficios que se espera obtener de este traba1o son#
a/ Los desarrolladores podrn probar aplicaciones basadas en
componentes en forma sistemtica , se podr e+aluar la adecuacin de una
componente para una aplicacin dada$
b/ (l modelo de defectos ser+ir como base para completarlo ,
me1orarlo- a,udando a sistematiar los problemas asociados con el S%C$ 4
partir del mismo se podrn generar nue+os , me1ores m2todos de prueba
para el S%C$
E
c/ 4l asegurar que una aplicacin basada en componentes satisface los
requerimientos impuestos- se contribu,e al a+ance de un mercado de
componentes$
d/ 4l modelar la arquitectura de una aplicacin con +istas a las pruebas-
automticamente se est +erificando la aplicacin misma , se pueden
emplear una serie de recomendaciones pre+enti+as- de utilidad especial a
quienes desarrollan componentes$
e/ (l contar con m2todos , *erramientas para probar el software es un
elemento importante para el desarrollo de la industria de software en
nuestro pas$ 4s- este traba1o colabora a que dic*a industria pueda acceder
a mercados mundiales$
f/ La realiacin de pruebas en forma sistemtica contribu,e al
aseguramiento de la calidad del software- a)n cuando no sea el )nico
aspecto a considerar$ 4dems- cuando no *a, acceso a todo el proceso de
desarrollo ni al cdigo fuente .caso del S%C/ las pruebas resultan una
*erramienta indispensable para asegurar la seleccin de partes de calidad ,
la integracin de aplicaciones de calidad$
Organizacin
(l traba1o se organia en dos partes- donde la primera presenta las bases de las
que parte el desarrollo propuesto , la segunda el traba1o propiamente dic*o$
(n la primera parte- las bases inclu,en dos captulos$ (l primero presenta la
problemtica del desarrollo de software de empresa- el software basado en
componentes , elementos de arquitectura de software$
(l segundo captulo presenta el estado actual de prueba de software basado en
componentes$
La segunda parte comprende cuatro captulos$ (l captulo tres formalia lo que se
entender por software basado en componentes , su modelado a tra+2s de un
lengua1e descripti+o de arquitectura$
(l captulo cuatro se dedica al modelo de defectos que se propone$
(l captulo cinco describe los m2todos de deri+acin de pruebas aplicables al
S%C$ !ara ello se analian di+ersas formas de acoplamiento entre componentes$
Tanto el anlisis de acoplamiento como los m2todos propuestos parten de la
descripcin arquitectnica del software$
(l captulo seis describe la estrategia de prueba propuesta- concretada en un
procedimiento algortmico$
(l traba1o se complementa con un ap2ndice que muestra la aplicacin del lengua1e
propuesto al modelado de di+ersos elementos de la plataforma Ja+a &$
=
Ca!0tu)" 4 S"$t%are +asad" en
C"#!"nentes*
Desde *ace a"os se *a especulado sobre la con+eniencia de construir software
reutiliando elementos$ Jacia ese fin se *an desarrollado di+ersos mecanismos-
como macros- bibliotecas de funciones , de clases , di+ersas +ersiones de los
llamados componentes$ 4)n cuando este propsito de reuso *a e0istido largo
tiempo- es en los )ltimos a"os que se +a concretando- debido a la comple1idad
creciente del software- las di+ersas caractersticas de interoperabilidad , al rpido
cambio de plataformas$
(n los )ltimos cinco a"os se *a *ablado de software plug and play- de
componentes disponibles en el mercado , otras +ariantes de lo que se conoce
como componentes$ Sin embargo- no e0iste un acuerdo en lo que debe
considerarse componente , qu2 ser el software basado en componentes$ (0isten
ciertas ideas ms o menos difundidas que *acen notar la liga e0istente entre este
tipo de software , la descripcin arquitectnica del software- tambi2n en gran
desarrollo por la misma causa de la comple1idad del software$
4s- para iniciar el presente traba1o se *ace necesario re+isar lo que se entiende
por componente , por software basado en componentes- as como e0plorar su
cone0in con arquitectura de software- como una base de la cual puedan partir
esfueros relacionados con su prueba$
(n este captulo se principia por re+isar la problemtica que lle+a al desarrollo de
software basado en componentes .S%C/ , se analian aspectos relacionados
como arquitecturas de software , la naturalea del software basado en
componentes- concretndolo en una +isin bre+e de las tres plataformas
dominantes en el incipiente mercado de componentes$
:
4*4 Pr"b)e#,tica de) desarr"))" de s"$t%are
(l desarrollo de software *a e+olucionado desde que era una tarea de unos pocos
e0pertos que creaban programas lnea por lnea- para satisfacer necesidades de
grupos reducidos .una empresa o unos pocos indi+iduos/ *asta grandes empresas
que preparan software para uso masi+o- en ambientes difciles de restringir- que
deben +enderse a ba1o precio , satisfacer necesidades cambiantes$ La labor de
desarrollar software se +a tornando ms comple1a cada +e$
(n este conte0to se pueden identificar una serie de tendencias que +an
conformando la manera de *acer software#
o !resin para reducir costos- a la +e que se termine en tiempos reducidosI
o 9apide de cambio- en necesidades- en formas de uso- en lengua1es ,
sistemas operati+os , en equipos donde se e1ecutar el softwareI
o 4umento de los sistemas distribuidos- inclu,endo los llamados de
clienteser+idor
, los de +arios ni+eles .tiers/$
La primera tendencia fa+orece una orientacin al reuso de productos de software-
en forma cada +e ma,or$ (l desarrollo desde cero es lento- su1eto a muc*as
equi+ocaciones que generan defectos que ms tarde se manifestarn como fallas
del sistema$ Si se apro+ec*an unidades terminadas- probadas , usadas- se tiene
cierta confiana que tendr menos problemas que una equi+alente reci2n
desarrollada$ Tambi2n se espera reducir el tiempo de desarrollo- pues parte de la
nue+a aplicacin ,a est disponible$ Fb+iamente este es un panorama ideal- que
deber ser matiado , re+isado- como lo ser aqu mismo un poco adelante$
La segunda tendencia- rapide de cambio lle+a a buscar- entre otras cosas- la
independencia de la plataforma , el logro de la liga pospuesta *asta el lmite entre
las partes de una aplicacin$ La independencia de la plataforma se *ace
indispensable cuando la rapide de cambio de tecnologa en el *ardware torna
imposible aferrarse a un equipo particular$ (n cuanto a la plataforma de software-
aunque los cambios son menores- no de1a de *aberlos a gran +elocidad$ 4 ni+el
de las propias aplicaciones- surgen +ariantes de cada uno de sus mdulos- con
me1oras en alg)n aspecto- lo que *ace necesario poder reemplaarlos sin re*acer
el sistema completo$ La liga pospuesta *asta el lmite permite que 2sta se realice
1usto en el momento que se requiere la funcionalidad de un mdulo , slo mientras
se la necesita$
La preferencia *acia los sistemas distribuidos *a sido consecuencia de di+ersos
factores# el gran desarrollo de redes de todo tipo de alcancesI la distribucin
natural de datos , procesos en empresas grandes- como bancos- transporte a2reo
, distribuidoras de alimentosI el 20ito de los equipos peque"os frente a los
grandes sistemas centrales de *ace unos a"os$ 4ctualmente resulta ms
econmico , confiable apro+ec*ar una red de computadoras personales para
realiar una labor de empresa que centraliar el traba1o en un gran equipo$
;'
Combinando la independencia de plataforma con el aumento de los sistemas
distribuidos se tiene una tendencia a la interoperabilidad- es decir- a la capacidad
de las pieas de software de cooperar- a)n cuando pertenecan a diferentes
plataformas- tanto de *ardware como de software$
Como partes de la solucin a la situacin descrita *an surgido +arios esfueros#
por el lado de implementacin *an surgido ob1etos distribuidos- modelos
clienteser+idor
, a*ora el software basado en componentesI por el lado de modelado ,
anlisis se *a a+anado en conceptos de arquitectura de software , en lengua1es
para describir arquitecturas .LD4/
Los +ariados esfueros con+ergentes en el desarrollo moderno de software
buscan reutiliar elementos que resulten interoperables- posponiendo su liga lo
ms posible de modo que pueda adaptarse a cambios de necesidades- de
+ersiones , actualiaciones de plataforma$ 4 software que cumple ms o menos
con tales caractersticas se le dan di+ersos nombres- como megaprogramacin-
software plug and play , software basado en componentes$ (n este traba1o se
emplear este )ltimo- por ser el que +a ganando ms aceptacin$
4dems de las tendencias mencionadas- algunos desarrollos particulares *an
contribuido a dar impulso al software basado en componentes .S%C/$ (ntre otros
resultan de importancia#
H Documentos compuestos# *ace algunos a"os se comen a integrar en
documentos )nicos lo que antes eran productos separados de aplicaciones
diferentes- como te0tos- ilustraciones grficas , tablas$ Tales elementos
resultan comunes en ambientes de negocios , resultaba mu, comple1o su
desarrollo por separado , su integracin manualI di+ersos desarrolladores
atacaron el problema logrando integrar tales partes de modo que se
presentaban como un solo resultado$
H 4mbientes +isuales de desarrollo# para acelerar el desarrollo de software se
crearon ambientes de desarrollo que permitan editar cdigo fuente-
compilarlo- depurarlo- imprimirlo- ligarlo , e1ecutarlo$ 3n paso ms fue el
desarrollo de interfaces grficas para el usuario , su cone0in con el cdigo
por medio de e+entos asociados con diferentes ob1etos$ 4s naci una
forma de desarrollo centrada en la interfa de usuario que se ensambla
+isualmente- mo+iendo elementos seleccionados de un men) ,
conectndolos de di+ersas formas$ Destaca en este aspecto el 20ito de
8isual %asic$
Los elementos presentes en documentos compuestos , las partes de una interfa
grfica fueron denominadas McomponentesN , eso impuls al S%C$
Las caractersticas del desarrollo de software que se +islumbra traen sus propios
problemas$ (l reuso- por e1emplo- es mu, )til si se cuenta con productos de buena
calidad , m2todos adecuados de ensamble$ Sin embargo- esto no siempre es
;;
posible$ !or e1emplo- los productos implementados se someten a pruebas- las
cuales descansan- usualmente- en m2todos estadsticos que garantian una cierta
cobertura de los posibles casos de uso- pero no del total$ 4l combinar dos
elementos probados en esas circunstancias- de1a un amplio margen a problemas
entre ellos$ Ftro caso deri+a del cambio de conte0toI un elemento probado en un
cierto ambiente puede funcionar perfectamente por +arias raones# nunca usa
alguna parte de su cdigo o e0isten defectos pero son compensados por otros
elementos$ 4l cambiar el conte0to- una o las dos situaciones de1an de +aler-
apareciendo fallas$ 3n )ltimo problema deri+ado del reuso es el grado del mismoI
difcilmente se reusan los elementos e0actamente- siendo ms probable que se
reutilice parte de su funcionalidad$ De ese modo- el resto +iene a ser una carga
para el nue+o sistema , una tentacin para que el desarrollador agregue funciones
de su cosec*a al nue+o sistema$
(l t2rmino componente se *a empleado largo tiempo asociado con el reuso$
5nicialmente se aplic a macros que redu1eron el traba1o de programar en lengua1e
ensamblador , tambi2n a troos de cdigo fuente e incluso programas completos
que solamente se adecuaban a cambios peque"os .especialmente en CF%FL/I
luego a funciones , subrutinas que luego se inclu,eron en bibliotecas-
comenando a reutiliarse en forma ms amplia$ Ms adelante a manera de
mdulos , luego de clases- que tambi2n se agruparon en bibliotecas$
!or el lado de modelado- los impulsores de la arquitectura de computadoras
utilian como elementos bsicos para cualquier arquitectura componentes ,
conectoresI las primeras para representar elementos computacionales acti+os o
pasi+os .almacenamientos de datos/ , los segundos para representar la
interaccin entre componentes$ (n este conte0to el t2rmino NcomponenteN puede
asociarse con cualquier unidad contenida en un sistema , a)n el sistema
completo$
(n la actualidad- algunos de los pocos autores que traba1an sobre componentes
mane1an el t2rmino KcomponenteL en forma indistinta para elementos tradicionales-
modernos componentes , elementos abstractos en arquitecturas de software .por
e1emplo ?@orris et al- &'''A/$
4 pesar de las posibles confusiones- el uso de arquitecturas de software como
modelos de sistemas resulta de gran utilidad- especialmente cuando el software es
comple1o$ !or esta ran se emplear a lo largo de este traba1o , sus elementos
principales se analian en la siguiente seccin$
4*5 Ar3uitectura de s"$t%are
Conforme el software se *ace ms comple1o aumenta la necesidad de contar con
*erramientas de modelado ms poderosas$ Como au0iliar para el dise"o de
sistemas , tambi2n para el anlisis de sistemas nue+os , e0istentes- se *a
desarrollado el concepto de arquitectura de software$ Grosso modo- la arquitectura
de software de un sistema es un modelo de su estructura- presentando sus partes
;&
, la relacin entre ellas$ (sta +isin tosca permite una gran +ariedad de
KarquitecturasL- donde la ma,ora se reducen a diagramas simples donde se
presentan un grupo de partes o componentes , sus cone0iones$ (n realidad *ace
falta ms que eso para poder aplicar m2todos de anlisis- +erificaciones ,
automatiacin de la implementacin$
(n esta seccin se re+isan elementos bsicos de arquitecturas de software , en
especial algunos lengua1es descripti+os de arquitectura$ Se *ace tambi2n una
re+isin de los elementos que aportan , los que faltan para su empleo en la
prueba de software$
1.2.1 Conceptos bsicos e Ar!"itect"ra e soft#are
La arquitectura de un sistema corresponde a su estructura$ Como abstraccin
empleada para modelar , analiar los sistemas tiene muc*a libertad para elegir
representacin- elementos constituti+os , ni+el de abstraccin- pero su eleccin
debe fundamentarse en las necesidades que pretende satisfacer- ,a sea gua para
el dise"o- dise"o detallado- documentacin de la implementacin o con fines
comerciales$
4unque *a e0istido informalmente por un buen tiempo- fue a mediados de la
d2cada de ;::' que comen a tomar forma el concepto de arquitectura de
software$ (ntre los primeros traba1os dedicados al tema se tiene el de ?Garlan ,
S*aw- ;::BA- en el que se establece#
KCualquier arquitectura es una coleccin de componentes computacionales
1unto con descripciones de interaccin .conectores/$ !uede +erse como un
grafo con las componentes como nodos , los conectores como arcosL$
4naliando los sistemas como se *an dado en la realidad- se descubre que
e0isten patrones que se repiten- dando paso al concepto de estilo arquitectnico$
4l respecto- Garlan , S*aw definen#
K3n estilo arquitectnico define una familia en t2rminos de patrones de
organiacin estructural- determina +ocabulario- 1unto con restricciones
sobre las combinaciones posibles .topolgicas- descripti+as , semnticas/$L
Ms tarde se refinan estos conceptos$ La arquitectura de software tiene que +er
con la estructura de sistemas- la organiacin del software- la asignacin de
responsabilidad a los componentes , el aseguramiento de que la interaccin entre
componentes satisfaga los requerimientos del sistema ?S*aw , Clements- ;::DA$
!or estilo arquitectnico se considera el con1unto de reglas de dise"o que
identifican las clases de componentes , conectores que se pueden emplear para
componer el sistema o subsistema- 1unto con restricciones locales o globales
acerca de cmo se realia la composicin ?S*aw , Clements- ;::DA$
;<
!ara %usc*mann , sus colaboradores ?%usc*mann et al- ;::DA los estilos
arquitectnicos corresponden a patrones- como sigue#
K3n patrn de arquitectura de software describe un problema de dise"o
particular- recurrente- que surge en conte0tos especiales de dise"o ,
presenta un esquema gen2rico- bien probado- de solucin$ (l esquema de
solucin se especifica describiendo las componentes que lo constitu,en-
sus responsabilidades , relaciones- as como la manera en que colaboranL$
%ass , sus colaboradores ?%ass et al- ;::EA definen arquitectura como#
KLa arquitectura de software de un programa o sistema de cmputo es la
estructura o estructuras del sistema- que comprenden componentes de
software- las propiedades +isibles e0ternamente de dic*os componentes ,
las relaciones entre ellosL$
Ms recientemente- DNSoua , Cills definen#
K4rquitectura# abstraccin de un sistema que describe las estructuras de
dise"o- las relaciones- reglas o principios usados en muc*os dise"osL
?DOSoua , Cills- ;:::A
(n esa definicin se mecla un poco el concepto de estilo con el de arquitectura$
(n los )ltimos cinco a"os *a ido creciendo el inter2s por la arquitectura- pero
muc*as +eces no *a pasado de la parte topolgica indicada por S*aw- quedando
as en diagramas de nodos , arcos- con poco +alor para traba1ar con ellos$ 4l
mismo tiempo- los autores *an centrado muc*os esfueros en coleccionar un buen
n)mero de estilos arquitectnicos que ocurren en sistemas e0itosos- que cubren el
software conocido- pero que son de poca a,uda para desarrollos no+edosos$
(ntre quienes estudian las arquitecturas e0isten di+ersos enfoques en los que
+ara la importancia , propiedades que se asigna a los conectores$ !or e1emplo-
4llen , Garlan ?4llen , Garlan- ;::=A slo consideran conectores que enlaan a
dos componentes- sin otras +ariantes como cone0in entre ms de dos
componentes o el empate de conectores en serie$ Sin embargo- estos autores
desarrollan a fondo m2todos de e0presin del funcionamiento del conector$
Ftros autores- como Me*ta- Med+ido+ic , !a*d7e ?Me*ta et al- ;:::A- ?Med+ido+ic
et al- ;:::A desarrollan el concepto de conector *asta incluir la cone0in de +arios
componentes$ Con ese enfoque se *a modelado el ambiente de (nterprise Ja+a
%eans como un gran conector ?Sousa , Garlan- ;:::A$
(n el camino para me1orar la situacin- surgen los lengua1es descripti+os de
arquitectura- que- si bien son a)n e0perimentales- *an puntualiado muc*os
elementos rele+antes , descuidados de la arquitectura de sistemas , ofrecen
;B
*erramientas para analiar dise"os , para desarrollar nue+os estilos$ (n la
siguiente seccin se trata este tema$
Di+ersos autores *an notado que los conceptos de arquitectura pueden aplicarse a
diferentes ni+eles- seg)n el ni+el de abstraccin donde se sit)a el desarrollador$
4s- %usc*mann , sus colaboradores ?%usc*mann et al- ;::DA proponen tres
ni+eles#
i$ !atrones arquitectnicos- orientados a la estructura de sistemas a
partir de subsistemasI
ii$ !atrones de dise"o- que refinan los subsistemas en componentes ,
describe la comunicacin entre ellosI
iii$ (0presiones idiomticas- que representan patrones a ni+el de
implementacin$
!or su parte- ?Moriconi , 9iemensc*neider- ;::EA consideran que e0iste toda una
1erarqua de arquitecturas$
(n realidad- parece que el punto cla+e de una arquitectura reside en el concepto
de conector$ Si se consideran conectores mu, primiti+os- tales como la liga de
mdulos o el mecanismo de in+ocacin de subrutinas- el modelo arquitectnico
ser de ni+el ba1o- cercano o situado en la implementacin$ !or otro lado- con
conectores ms comple1os se +a ascendiendo en ni+eles de abstraccin .por
e1emplo el estilo !ipes and Filters- citado siempre en relacin a arquitectura-
pro+ee un ni+el ms o menos alto/$ Lle+ndolo a un e0tremo se podra tener toda
una aplicacin como un gran conector que une a personas con fuentes de datos o
de clculos$
(l ni+el adecuado depender de las necesidades$ !ara el dise"o general de un
sistema grande de tipo cliente ser+idor- no resulta mu, )til describir su arquitectura
en t2rminos de llamadas o ligas de mdulosI en cambio- para la planificacin de
pruebas de integracin de un sistema tradicional resulta adecuado el uso de
rboles de mdulos , rboles de llamadas ?Jorgensen- ;::>A$
1.2.2 $eng"ajes escriptivos e ar!"itect"ra %$&A'
(n la actualidad- la ma,ora de las descripciones llamadas KarquitecturaL se
reducen a diagramas ms o menos desarrollados$ !or e1emplo- la figura ; muestra
un diagrama de arquitectura de Ja+a &$
(stos diagramas son enga"osos , totalmente su1etos al gusto de quien los
prepara$ 3n e1emplo de confusin es el siguiente# en la figura ;$; aparece un
elemento marcado KcontenedorL- el cual rodea o contiene un elemento menor
marcados K5nstancia de %eanL$ (ste contenedor a su +e aparece contenido en
otro elemento ma,or marcado KSer+idor (J%L$ Sin embargo- atendiendo a la
semntica de las relaciones entre dic*os elementos- corresponden ms a un
sistema de capas- conocido *ace tiempo en los modelos arquitectnicos$ %a1o ese
modelo- la parte central de la figura ;$; aparecera como en la figura ;$&$
;>
Figura ;$;$ (1emplo de diagrama arquitectnico- correspondiente a Ja+a &
.adaptado de ?S3@- ;:::A/$
Figura ;$&$ 8ersin alternati+a de figura ;$;
Con el fin de eliminar tanto como sea posible la ambigPedad de tales
representaciones- se *an desarrollado esfueros dirigidos a e0presar formalmente
los modelos arquitectnicos- concretados en los llamados lengua1es descripti+os
de arquitectura .LD4/ o al por sus siglas en ingl2s$
Los LD4 en general tienen como propsitos#
o describir la arquitectura conceptual de sistemas , familias de ellos
o describir el comportamiento de sistemas en forma abstracta- relati+amente
independiente de la implementacin
o pro+een notacin formal
o promue+en el uso de *erramientas para anlisis , desarrollo
Los LD4 *an seguido di+ersos caminos- seg)n el propsito particular de sus
dise"adores o las circunstancias en que traba1an$ Se pueden distinguir cuatro
grandes enfoques#
a/ adaptar lengua1es pree0istentes en campos afines- como simulacin ,
sistemas de tiempo real o diagramas de estados
b/ emplear lengua1es o modelos usados en dise"o de sistemas- especialmente
los de tipo orientado a ob1etos
c/ desarrollar lengua1es especficos
d/ mecla de lengua1es especficos con modelos de dise"o
(J%
Contenedor
Ser+idor (J%
5nstancia de
%ean .(J%/
Contenedor
Ser+idor (J%
;D
La primera opcin inclu,e esfueros tales como los Module 5nterconnection
Languages o M5L , lengua1es como L5L(4@4$ Dado que su propsito es diferente
al de modelado arquitectnico , se adaptan a tal uso- otra adaptacin para los
propsitos del presente traba1o los con+ertira en algo poco naturalI por ello no se
les tratar$ !uede consultarse informacin en ?Med+ido+ic , Ta,lor- &'''A$
La segunda opcin apela a la difusin de lengua1es , modelos de dise"o- en
especial 3ML- para no buscar otros elementos- pensando facilitar las cosas a los
desarrolladores$ (ste enfoque presenta problemas- ,a que no distingue entre
componentes en sentido arquitectnico , otros elementos .incluso ba1o el mismo
nombre/ con semntica diferente$ (ntre otros- se corre el riesgo de confundir
componentes con clases$ (n particular para este traba1o este enfoque no resulta
pro+ec*oso- por lo cual tampoco se tratar$
(l tercer enfoque *a producido en los )ltimos a"os un pu"ado de lengua1es
especficos- la ma,ora a)n en desarrollo$ (ntre ellos se pueden citar Crig*t ?4llen
, Garlan- ;::=A- C& ?9obbins et al- ;::=A , 9apide ?Luc7*am- ;::DA$ (ste tipo de
lengua1es considera importante el anlisis de los modelos para e0traer informacin
)til al desarrollador- por lo cual resulta de inter2s para 2ste traba1o- a)n cuando el
uso de LD4 para pruebas *a sido tocado solo marginalmente- por e1emplo en
?9osenblum- ;::=A$ 4ba1o se describen algunos elementos importantes de algunos
lengua1es$
(l )ltimo enfoque se plantea un difcil balance entre los lengua1es especficos , los
de uso general entre los desarrolladores- buscando maneras de adaptar estos
)ltimos o con+ertir elementos entre ambas categoras$ (ste enfoque resulta de
especial inter2s para nuestro traba1o- por lo que se tratar bre+emente un poco
ms adelante$
4*5*5*4 Lengua6es es!ec0$ic"s !ara descri!cin ar3uitectnica*
Los conceptos de arquitectura de software se con+ierten en elementos )tiles en el
desarrollo , anlisis de software al concretarlos en lengua1es de descripcin de
arquitectura .LD4/- los cuales pro+een una notacin formal$ 3na definicin de
2stos lengua1es es la siguiente#
KLD4 son lengua1es que suministran caractersticas para modelar la
arquitectura conceptual de un sistemaI pro+ee sinta0is concreta , marco
conceptualL$ ?Garlan et al- ;:::A
(l marco conceptual inclu,e tpicamente una teora sub,acente , que permite
e0presar la funcionalidad de las componentes , la interaccin a tra+2s de un
conector$ (sta teora puede ser la de mquinas de estados- redes de !etri o CS!
de Joare$
De acuerdo con ?4llen , Garlan- ;::=A- para que un LD4 resulte +lido debe
poseer e0presi+idad , capacidad de anlisis$ La e0presi+idad significa que debe
;E
poder representar casos comunes- interacciones dinmicas , comple1as adems
de +ariaciones menores en los conectores$ La capacidad de anlisis significa que
deben permitir entender el comportamiento de conectores independientemente de
su conte0to- raonar acerca de la composicin , presentar fle0ibilidad ante
incompatibilidades$
De acuerdo con ?Med+ido+ic , Ta,lor- &'''A- e0isten cuatro elementos necesarios
en todo lengua1e descripti+o de arquitectura#
H componente
H conector
H configuracin .de sistemas , subsistemas/
H soporte para *erramientas
4lgunos autores destacan el papel del puerto- pero se le puede considerar
integrado en los componentes$
La ma,ora de los LD4 actuales tienen apenas unos cinco o seis a"os de
desarrollo- *abiendo e+olucionado en algunos casos de lengua1es de otras
disciplinas que resultan fronterios con ellos$ 9ealmente es un campo mu, 1o+en
a)n$
Los LD4s parten de una idea general de que la arquitectura de una piea de
software puede resumirse en la descripcin de sus elementos- as como del
comportamiento de 2stos , del con1unto$ 4 +eces se agregan reglas de
construccin o patrones de uso tpicos ?DNSoua , Cills- ;:::A$ Los elementos
usualmente son de dos tipos# componentes , conectoresI los componentes son los
encargados de realiar computaciones , los conectores son responsables de la
comunicacin entre ellos$
7rigt2*
(ste lengua1e- desarrollado en CM3 por 4llen- Garlan , sus colaboradores- da
particular 2nfasis equilibrado a componentes , conectores$ La descripcin de una
aplicacin consta de tres partes# una descripcin de elementos .componentes ,
conectores/- una lista de instancias de los elementos , un con1unto de
combinaciones o cone0iones entre elementos$ La descripcin del comportamiento
de los di+ersos elementos se realia por medio de un lengua1e deri+ado del
lgebra de procesos de Joare- CS! ?Joare- ;:=>A$ 3tilia )nicamente un
subcon1unto de elementos de CS! , realia una serie de adaptaciones$ Cada
proceso cuenta con un alfabeto que re)ne a los diferentes e+entos en que toma
parte$ !ermite combinar procesos en paralelo , por alternati+as dependientes de
decisin interna o e0terna$ Tambi2n permite asignar identificadores a procesos o
partes de ellos- de modo que se puedan usar- inclusi+e en forma recursi+a$
4dems del alfabeto- un proceso tiene un con1unto de fallas .pares de traas ,
con1untos de e+entos/ , de di+ergencias .traas que lle+an a comportamiento
arbitrario/$
;=
Los componentes se modelan definiendo los puertos o elementos donde se
conectarn , la computacin especfica que realian$
Los conectores se modelan como roles- que definen los comportamientos
asociados a los puertos que se conectarn- , como pegamento- que describe el
comportamiento con1unto del conector$ @tese que este pegamento se definir
realmente al tiempo de implementacin$ Los roles , los puertos 1uegan papeles
similares- pero un puerto puede usar solamente un subcon1unto de las
potencialidades de un rol$
(n las figuras siguientes se muestra un e1emplo tomado de ?4llen , Garlan- ;::=A
para un sistema cliente ser+idor$
Figura ;$<$ Sistema cliente ser+idor$
Crig*t utilia como teora sub,acente una +ariante del CS! de Joare- con el cual
se e0presa tanto la funcionalidad de las componentes como la manera de
interactuar de los di+ersos papeles en un conector- a tra+2s del KpegamentoL
.glue/ que es parte del conector$ 4l igual que CS! es un lgebra de procesos$
Muestra el funcionamiento en forma de protocolos interactuando$ 3n e1emplo de la
notacin es el que sigue#
c"nnect"r C6S6connector Q
r")e Client Q .requestR0 resultS, Client/ H T
r")e Ser+er Q .in+o7eS0 returnR, Ser+er/ T
g)ue Q .Client$requestS0 Ser+er$in+o7eR0 Ser+er$returnS,
Client$resultR, g)ue/ T&
& La notacin- bre+emente- es como sigue# e ! representa un e+ento que precede la realiacin
del proceso !I representa una alternati+a entre dos procesos dependiendo de un factor e0ternoI
H representa una decisin no determinstica internaI eS0 representa un e+ento que produce
entrada de datosI eR0 un e+ento que produce salida de datosI T significa un proceso que termina
con 20ito , se para$
Cliente Ser+idor
;:
Figura ;$B$ Descripcin de cliente ser+idor en Crigt*$
C5
C& es un estilo arquitectnico- descrito en ?9obbins et al- ;::=A , en ?Med+ido+ic
et al- ;:::A- orientado a sistemas donde domina la interfaI los conectores
bsicamente transmiten mensa1es , las componentes guardan estado- realian
operaciones e intercambian mensa1es a tra+2s de un par de interfaces# superior e
inferior$
(l estilo de C& obliga a +isualiar el sistema en una serie de capas
comunicndose +a conectores que unen interfaces .+er figura ;$>/$ Cada interfa
representa un con1unto de mensa1es que pueden en+iarse , un con1unto de
mensa1es que pueden recibirse$ Cada interfa se relaciona con un solo conector$
Los conectores no permiten formas de comunicacin +a +ariables compartidas u
otros mecanismos diferentes a mensa1es- con lo cual se obtiene cierta
independencia del sistema operati+o$
Los componentes tienen cuatro partes# un ob1eto interno con estado ,
operacionesI una en+ol+ente que super+isa mensa1es recibidos , en+a los de
salidaI una especificacin de dilogo que mapea mensa1es con operaciones , un
traductor opcional que modifica los mensa1es$
S,stem Simple(0ample
component Ser+er Q
port pro+ide ?pro+ide protocolA
spec ?Ser+er specificationA
component Client Q
port request ?request protocolA
spec ?Client specificationA
connector C6SHconnector Q
role client ?client protocolA
role ser+er ?ser+er protocolA
glue ?glue protocolA
5nstances
s# Ser+er
c# Client
cs# C6S6connector
4ttac*ments
s$pro+ider as cs$ser+erI
c$request as cs$client
end Simple(0ample$
&'
B516 76 75891
C9:;9.6.86
76 .6<9/-91 1
C9:;9.6.86
76 .6<9/-91 2
I.86=>5? 76
@1@5=-9
/9.6/89=61
Figura ;$> e1emplo de estructura de sistema en C&
4sociado con C& e0iste un lengua1e denominado C&S4D(L .C& Software
4rc*itecture and (+olution Language/ descrito en el traba1o de ?Med+ido+ic et al-
;:::A$
(n C&S4D(L se especifica una arquitectura en tres partes# tipos de
componentes- tipos de conectores , topologa$ (sta )ltima describe las instancias
de componentes , conectores a emplear , su interaccin$ (n la figura ;$D se
muestra un segmento de cdigo de este lengua1e$
Las componentes contienen descripcin de sus in+ariantes , pre , pos
condiciones para sus operaciones- e0presado en lgica de primer orden$
ACME
4 pesar de *aber pocos lengua1es descripti+os de arquitectura , de los pocos a"os
de su desarrollo- e0iste ,a un lengua1e intermediario que permite el mapeo ,
con+ersin de uno a otro- al menos en aspectos en que e0iste compatibilidad$ (ste
lengua1e es 4CM(- debido al grupo 4%L( de Carnegie Mellon 3ni+ersit,$
Documentacin del mismo puede encontrarse en el traba1o de Uompane7 en la
pgina de 5nternet www$cs$eduVWacmeVacmeHe0tendingHacme$*tml$
4CM( describe arquitecturas , familias de ellas$ @o detalla comportamiento-
permitiendo que se anote de modo que una *erramienta adecuada la con+ierta a
un lengua1e especfico o bien la entienda un ser *umano$
(ste lengua1e proporciona formas de representar tipos de elementos- sistemas ,
familias a partir de grafos de componentes , conectores , mecanismos de
descomposicin 1errquica de componentes , conectores en subsistemas$
&;
Figura ;$D (1emplo en C&S4D(L .adaptado de ?Med+ido+ic et al- ;:::A
!or su naturalea- 4CM( sir+e como referencia para otros lengua1es- mecanismo
de traduccin , estandariacin de *erramientas para mane1o de arquitecturas$
(n su sinta0is emplea elementos del estilo de CXX- como puede +erse en los
fragmentos de e1emplo- tomados del documento de Uompane7 ,a mencionado#
Component T*eFilter Q Y
!ort inI
!ort outI
!ropert, implementation # String Q
Kw*ile .Rin$eof/ Y in$readI in$readI computeI out$writeZLI
Z
Connector collaboration Q Y
9ole requestorI
arc*itecture CargorouteS,stem is Y
componentHt,pes Y
component Deli+er,!ort is e0tern Y!ort$c&IZ
$$$
Z
conectorHt,pes Y
connector FiltConn is Yfilter msgHfilterIZ
$$$
Z
arc*itectural topolog, Y
componentHinstances Y
9unwa, # Deli+er,!ortI
$$$
Z
connectorHinstances Y
3tilit,Conn # FiltConnI
$$$
Z
connections Y
connector 3tilit,Conn Y
top SimCloc7- DistanceCalcI
bottom 9unwa,- Truc7I
Z
$$$
Z
Z
Z
&&
9ole sla+e;I
9ole sla+e&I
!ropert,DistributionMap Q
Krequestor$request4 sla+e;$do[- sla+e&$do\I
requestor$request% sla+e;$do3 ] sla+e&$do8L
Z
S,stem ClientSer+erS,stem Q Y
component ser+er Q Y $$$Z
connector re Q Y$$$Z
attac*ments Y ser+er$request to req$requestorI
client$ma7erequest to req$requesteeI
Z
Z
C"#!araci"nes
!ara comprender los elementos comunes , las diferencias entre los LD4
e0istentes con+iene consultar dos traba1os rele+antes$ 3no de ellos- de
?Med+ido+ic , Ta,lor- &'''A- presenta una clasificacin de di+ersos lengua1es
candidatos a ser LD4- inclu,endo casos fronteriosI tambi2n presenta un marco
adecuado para compararlos , as poder elegir el adecuado seg)n las
necesidades$ (n ese traba1o se describen elementos que se presentaron en las
subsecciones anteriores , se detalla cmo soporta cada lengua1e elementos tales
como componentes , conectores$
(l segundo traba1o- de Me*ta , sus colaboradores ?Me*ta et al- ;:::A discute
especficamente el tema de los conectores- que es- en cierta medida- el que
distingue ms fuertemente a los LD4 de otros lengua1es relacionados$ (n este
traba1o se modela cualquier conector como un ducto por el que se intercambian
datos , control$
Me*ta , sus colaboradores proponen cuatro categoras de ser+icios generales que
puede ofrecer un conector# comunicacin- coordinacin- con+ersin , facilitacin$
De este modelo se inclu,en en conectores di+ersos ser+icios +istos de manera
independiente en otros casos- como son# mensa1era- mane1o de persistencia-
transacciones$ Tambi2n identifican oc*o clases de conectores bsicos# llamadas a
procedimiento- acceso de datos- liga- KstreamL- e+ento- rbitro- adaptador ,
distribuidor$
Con las cuatro categoras de ser+icio , los oc*o tipos bsicos de conector- se
forma un marco que permite clasificar conectores ms o menos comple1os- que
pueden conectar ms de dos componentes$
&<
4*5*5*5 En$"3ues #i8t"s*
La opcin de emplear lengua1es mi0tos entre LD4 propios , m2todos o lengua1es
de dise"o parte del *ec*o de que los desarrolladores ,a mane1an 2stos )ltimos ,
no son mu, propensos a emplear otros$ (n especial- en los )ltimos a"os *a
ganado amplia aceptacin el enfoque del 3nified Modeling Language .3ML/-
sistematiado por la FMG$
4lgunos traba1os relacionados con este enfoque mi0to son los siguientes#
M"de)ar caracter0sticas es!ec0$icas de un )engua6e descri!ti&" de
ar3uitectura en !articu)ar9 usand" e)e#ent"s de UML*
(ste enfoque *a sido emprendido por 9obbins , sus colaboradores ?9obbins et al-
;::=A para e1emplificar la posibilidad de *acerlo$ (n su traba1o representan
caractersticas de los lengua1es Crig*t , C& utiliando 3ML$ !or e1emplo-
relacionan las operaciones en 3ML con los mensa1es de C&I representan
componentes , conectores de C& por medio de clases$ !ara el caso de Crig*t-
utilian diagramas de estados para la descripcin formal en CS!- los componentes
los representan como clases con un con1unto de puertos , una parte
computacional$
(n su traba1o consideran la con+eniencia de respetar la semntica de 3ML- que es
reforada por las *erramientas de desarrollo- a la +e que un mapeo- como los
que muestran- permite el empleo de *erramientas especficas de alg)n LD4$
5ncluso consideran el empleo de 4CM( como intermediario de traduccin$ 3n
comentario que *acen es mu, rele+ante para este enfoque mi0to#
K8isualiamos a los desarrolladores usando 3ML normalmente ,
*erramientas especficas de LD4 seg)n sean necesariasI ?$$$AL$
M"di$icaci"nes a UML !ara re!resentar c"nce!t"s de LDA
4 pesar de las con+eniencias de 3ML , de que inclu,e elementos de nombre
parecido- como el de componente- la semntica es un poco diferente , se
requieren adaptaciones si se pretende usarlo como un LD4$
4lgunas crticas acerca de la insuficiencia de 3ML como LD4 son las siguientes#
H (l concepto de componente de 3ML es ms bien para implementacin que
para dise"oI tiene una semntica +aga , se traslapa con otros
clasificadores ?Uobr,n- &'''AI
H 4l concepto de componente de 3ML no se aplican muc*as relaciones del
propio 3ML , no participan en diagramas de interaccin ?Garlan et al-
;:::AI
H Si se usan como elemento de modelado arquitectnico no *a, buenas
opciones para puertos , conectores- seg)n la comparacin que aparece en
?Garlan et al- ;:::AI
&B
H (l concepto de puerto no e0iste en 3ML , no se puede igualar con el de
interfa- ,a que aquel puede incluir implementacin ?Selic and 9umbaug*-
;::=AI
H (l concepto de conector no e0iste en 3MLI no basta la asociacin entre
componentes$
4 pesar de lo anterior- el atracti+o de usar 3ML es fuerte en la actualidad , e0isten
di+ersos enfoques de adecuar 3ML como LD4- *aciendo coincidir componentes-
puertos- sistemas , conectores con di+ersos elementos de 3ML# clases- ob1etos-
relaciones- componentes , paquetes$ Cada forma busca que el mapeo sea lo ms
natural posible , respete la ma,or parte de los conceptos de los LD4 , de 3ML$
(n general no resultan totalmente afortunados- aunque +an de1ando pistas de
cmo se podra adaptar 3ML$
Garlan , sus colaboradores ?Garlan et al- ;:::A analian , clasifican di+ersas
alternati+as de mapear conceptos de LD4 en conceptos de 3ML- analiando sus
+enta1as , des+enta1as$ Casi todas las adaptaciones *acen uso intensi+o de los
estereotipos para restringir los elementos seleccionados , que se acerquen a los
conceptos arquitectnicos$ 4l final es claro que ninguna adaptacin es la me1or
para todos los casos- quedando as abierta la cuestin$
3n aspecto importante al que llegan- a)n cuando no lo e0ploran- es considerar la
con+eniencia de crear una e0tensin a 3ML en forma de un perfil .profile/- lo cual
es una alternati+a aceptable en el medio de 3ML$ (ste perfil respetara la
semntica bsica de 3ML- por lo que podran emplearse las *erramientas
e0istentes$
Re)acin c"n !ruebas*
(l concepto de interaccin entre componentes es un elemento bsico de las
descripciones arquitectnicas , tambi2n es materia de inter2s en el campo de las
pruebas de integracin de software$ (ste inter2s com)n *a moti+ado que las
descripciones estructurales- ms o menos formales- se usen como gua en la
preparacin de pruebas de integracin$
(n el software tradicional se constru,e un rbol de mdulos que se usa como gua
en pruebas de integracin- especialmente para organiar el orden .top6down o
bottom6up/$ (l rbol de mdulos puede +erse como una descripcin arquitectnica
de ni+el ba1o$
(n software orientado a ob1etos se usan los diagramas de secuencia para
identificar secuencias de mensa1es que se acti+an a partir de un e+ento inicial$
4s pues- es natural sugerir el uso de las descripciones arquitectnicas modernas
como base para preparar pruebas de integracin$ Sin embargo *a, poco traba1o al
respecto$ 3no de los traba1os al respecto es el de ?9osenblum- ;::=A$
&>
!ara generar pruebas de integracin a partir de un LD4 sera necesario que 2ste
contara con +arios elementos como son#
H Topologa de la aplicacin basada en componentesI
H Comportamiento esperado de la interaccin entre componentesI
(l tema de pruebas ser tratado ampliamente en el captulo &$
4*: Natura)e'a de) s"$t%are basad" en c"#!"nentes
(l concepto de componente- como se di1o antes- *a e+olucionado , de *ec*o a)n
se encuentra indefinidoI sin embargo- analiando las di+ersas opiniones de
e0pertos tericos , de aquellos ligados a desarrollo comerciales- se pueden
determinar una serie de caractersticas rele+antes , se pueden indicar +arios
grupos de componentes$ 4 partir de sus caractersticas , del 2nfasis que se pone
a diferentes aspectos- se pueden clasificar las tendencias actuales en este campo
, situar la que ms resulta de utilidad para este traba1o$ 4s- en este captulo se
discuten el concepto de componente , las tendencias +isibles en la actualidad$
1.(.1 Concepto e componente.
!ara comenar- se muestran una serie de definiciones aparecidas en la literaturaI
sin que pueda considerarse e0*austi+a- s representa el panorama ms rele+ante$
Se presentan agrupadas en categoras mu, generales- para facilitar la tarea de
e0traer elementos comunes$
De$inici"nes genera)es ( tradici"na)es*
%ooc*- ;:=EA#
3n componente reutiliable de software es un mdulo lgicamente co*esi+o
, con poco acoplamiento que denota una sola abstraccin$
?Jacobson- ;::&A#
!or componentes queremos significar unidades preimplementadas que
usamos para reforar los constructos del lengua1e$ (stos se usan durante la
programacin , corresponden a los componentes en la industria de la
construccin$
?@ierstras , Dami- ;::>A#
3n componente de software es una abstraccin esttica con enc*ufes$
?Martin , Fdell- ;::DA#
3n componente es una piea de software que cumple con dos
caractersticas#
&D
a/ no depende de la aplicacin en que se utilia ,
b/ se puede emplear en di+ersas aplicaciones$
?Me,er- ;:::A#
3n componente de software es elemento de programa con propiedades#
a/ el elemento puede ser empleado por otros elementos
.clientes/- que pueden ser *umanos o programas-
b/ los clientes , sus autores no necesitan saber acerca de los
autores del elemento$
C"nce!t"s )igad"s c"n )a "rientacin a "b6et"s*
?Cant)- ;::DA
Los componentes son los elementos centrales de aplicaciones Delp*i$ ?$$$A
Los componentes Delp*i son clases$
?Frfali , Jar7e,- ;::EA
Los ob1etos distribuidos son- por definicin- componentes$
C"nce!t"s #"dern"s acad1#ic"s*
?%ronsard et al- ;::EA
3n componente es una unidad funcional de un sistemaI puede ir desde una
funcin de ba1o ni+el *asta una de alto ni+elI puede ser atmica o
compuestaI es reutiliable o compartible$
(l modelo de componentes difiere del de ob1etosI 2ste no contiene todos los
elementos necesarios para describir los componentes , su ensamble$
4tributos esenciales de componentes#
a/ independencia del conte0to .se conectan arbitrariamente/-
b/ transparencia de localidad-
c/ cone0in *eterog2nea$
?Sametinger- ;::EA
Componentes de software reutiliables son elementos autocontenidos-
claramente identificables que describen ,Vo realian funciones especficas-
tienen interfaces claras- documentacin apropiada , un propsito de reuso
bien definido$
&E
?S,pers7i- ;::EA
3n componente de software es una unidad de composicin que )nicamente
especifica contractualmente las interfaces , las dependencias e0plcitas del
conte0to$ 3n componente de software puede desplegarse independientemente
, es su1eto de composicin por terceros$
Grupo Gartner<#
3n componente de software e1ecutable es un paquete que puede ligarse
dinmicamente- formado por uno o ms programas administrados como
unidad , accedidos a tra+2s de interfaces documentadas que pueden
descubrirse al tiempo de e1ecucin$
?Urieger , 4dler- ;::=A
Los componentes de software son bloques reutiliables de construccin de
sistemas de software$ (ncapsulan aplicaciones o ser+icios t2cnicos con
sentido semntico$ Difieren de otros tipos de mdulos reutiliables en que
pueden modificarse- al tiempo de dise"o- en sus e1ecutables binarios-
mientras los dems lo *acen en su ni+el de programa fuente$
Los componentes restringen acceso +a una o ms interfaces p)blicas que
definen propiedades- m2todos , e+entos que permiten comunicacin$ Las
propiedades , m2todos representan una 4!5 tpica$
Los componentes e0isten , operan en contenedores que les brindan
conte0to compartido para interactuar con otras componentes , acceso a
ser+icios del sistema$
Urutc*ersB#
3n componente es una parte no tri+ial- casi independiente , reemplaable
de un sistema- que satisface una funcin clara en el conte0to de una
arquitectura bien definidaI un componente configura , pro+ee la realiacin
fsica de un con1unto de interfaces$
?Lewandows7i- ;::=A
Los componentes son las menores unidades autoadministradas-
independientes , )tiles de un sistema que traba1a en ambientes m)ltiples$
!uede ser un ob1eto- pero no es indispensable$
< Su definicin aparece en el resumen del Cor7s*op acerca de componentes realiado en la
5nternational Conference on Software (ngineering .5CS(:=/- reportado por ?%rown , Callnau-
;::=A$
B 5bid$
&=
?DNSoua , Cills- ;:::A#
3n componente- en generales un paquete co*erente de artefactos de
software que pueden ser desarrollados independientemente , entregados
como unidad que puede ser compuesta- sin cambios- con otras para formar
algo ma,or$
,#
3n componente- en cdigo- es un paquete co*erente de software
implementado- que
a/ !uede ser desarrollado , entregado independientementeI
b/ Tiene interfaces e0plcitas , bien especificadas para
ser+icios ofrecidos-
c/ Tiene interfaces e0plcitas , bien especificadas para
ser+icios requeridos-
d/ !uede componerse con otras componentes- tal +e
adaptando propiedades- sin modificarla$
C"nce!t"s #"dern"s c"#ercia)es*
?9ogerson- ;::EA
3n componente es una parte de un sistema- pero â diferencia de mdulos
, otros elementos6 es como una miniaplicacin que +iene lista para usarse$
!ara que funcione se requiere una *erramienta que especifique la manera
de crear componentes , armar aplicaciones$
Uindel .en ?%o0- ;::=A/
programacin orientada a componentesQ polimorfismo X liga realmente
pospuesta X encapsulamiento real , reforado X *erencia de interfaces X
reuso binario$
?9oman- ;:::A#
Componente de software es cdigo que implementa un con1unto de
interfaces bien definidas$ (s un segmento mane1able de lgica$ @o es una
aplicacin completa- no corre aisladamente sino como parte de un con1unto$
?Cindows- &'''A#
Componente# mdulo de software escrito para mane1ar un tipo particular de
informacin o un proceso particular$
&:
1.(.2 Anlisis e los elementos com"nes.
!ara apro+ec*ar los elementos anteriores- separaremos el concepto de
componente en +arios sentidos#
H tradici"nal- inclu,endo las definiciones generales , orientadas a ob1etosI
H #"dern"- que pretende distinguir las componentes de otras formas de
software reutiliadoI
H sentid" ar3uitectnic"- correspondiente a lo tratado en el captulo &- que
representa un metani+el- )til en el modelado de sistemas de todo tipo , de
S%C en particular$
!ara este traba1o- el tercer sentido resulta de inter2s como *erramienta de
anlisis- pero es el segundo el que resulta central para el logro de los ob1eti+os$
4s que en lo que sigue ser el discutido- a menos que se indique otra cosa$
Los elementos comunes los agrupamos en dos listas# los que aparecen de manera
e0plcita o implcita en la ma,ora de las definiciones- sin considerar el sentido- ,
las de aquellos que representan una diferencia entre el sentido tradicional , el
moderno$
E)e#ent"s c"#unes a t"das;
reuso
encapsulamiento
interoperabilidad
prefabricados
unidad con sentido semntico
independencia de otros componentes .ba1o acoplamiento/
ignorancia del origen
E)e#ent"s distinti&"s
funcionalidad clara
interfaces claras , documentadas
dependencias del conte0to claras , documentadas
unidad de despliegue
adecuacin de propiedades al tiempo de ensamblar
*eterogeneidad
contenedor
3n aspecto conflicti+o en diferentes enfoques de componentes es la posibilidad de
contar con un estado$ 4lgunos autores- como ?S,pers7i- ;::EA- insisten en la
necesidad de que el componente no tenga estado- para que pueda ser
compartido$ Sin embargo- los enfoques comerciales consideran e0plcitamente la
posibilidad de contar con componentes de datos .entidades/$ %a1o el enfoque
arquitectnico tambi2n e0iste esa posibilidad$
<'
1.(.( Aplicaciones basaas en componentes.
4)n cuando en la literatura se *a dado muc*a atencin a los componentes- no
sucede lo mismo con las aplicaciones desarrolladas a partir de ellos$ Tal parece
que se cree que si estn bien definidas- el conectarlas es lo de menos$
4 grandes rasgos- una aplicacin de S%C es un con1unto de componentes que
colaboran para resol+er un problema$
4lgunas aplicaciones se realian usando componentes disponibles
comercialmente
, creando el pegamento adecuado a pi2$ (ste enfoque presenta
problemas prcticos que no lo *an fa+orecido- como el reportado por ?Garlan et al-
;::>A$
Los desarrollos comerciales se *an reducido en sus alcances ofreciendo
infraestructura donde se puedan desplegar , conectar componentes de un mismo
modelo$ (ste enfoque es el correspondiente a las plataformas descritas en la
siguiente seccin , algunos marcos para empresa como el llamado !ro,ecto San
Francisco- de ?5%M- ;::EA$
3n par de e0cepciones a este panorama son las obras de ?Jerum , Sims- &'''A ,
?@orris et al- &'''A$ La primera especialmente- suministra un marco general-
bastante ambicioso- que propone toda una estructuracin de sistemas basados en
componentes- partiendo de componentes de ba1o ni+el formadas por unas cuantas
clases- a las que llama Kcomponentes distribuidosL$ Luego combina +arios de esos
componentes formando Kcomponentes de negociosL- de ma,or granularidad , que
deben corresponder a conceptos de negocios$ Finalmente forma sistemas a partir
de componentes de negocios .unos pocos/ , federaciones de sistemas$ 4s- ba1o
ese enfoque las aplicaciones basadas en componentes sern a su +e
componentes o sistemas de ellos$
(l enfoque de Jerum , Sims es a)n utpico- ,a que la estructura disponible
apenas est luc*ando por establecer lo que ellos llaman componente distribuido-
como seran las descritas en las plataformas dominantes$ De *ec*o- @orris , sus
colaboradores ?@orris et al- &'''A dicen que a la fec*a las llamadas Kcomponentes
de negociosL son ms bien sistemas completos que se conectan ms o menos a
fuera$
Seg)n Jerum , Sims- en la actualidad el desarrollo de aplicaciones basadas en
componentes es un poco frustrante por los costos ocultos$ 3na empresa tiene
como meta estrat2gica construir un sistema de informacin- pero luego descubren
que requieren componentes reutiliables- pero a)n no *a, mercado amplio- as
que deben plantearse la creacin de una fbrica de componentes- lo cual se
des+a bastante del propsito inicial ?Jerum , Sims- &'''A$ 4 eso se puede
agregar la necesidad de software intermedio para soportar los componentes- como
lo *acen notar ?@orris et al- &'''A$
<;
(l desarrollo de aplicaciones basadas en componentes sigue un ciclo de +ida mu,
similar al de otros tipos de software- pero conceptualiando los componentes
desde la recoleccin de requerimientos- primero en forma abstracta- de empresa-
pasando poco a poco a elementos concretos implementables$ La figura ;$E
muestra un posible ciclo de +ida tomado de ?Jerum , Sims- &'''A- pero que
resulta compatible con el mostrado por ?@orris et al- &'''A$ (n la figura se separa
la parte que corresponde propiamente a componentes , la que +iene a ser el
sistema , se inclu,en los ni+eles correspondientes de prueba$ 3na etapa no
incluida en el diagrama es el despliegue- que se presenta en todos los ni+eles de
integracin conforme se +an probando las partes terminadas$
R6A@6=-:-6.891
A.BC-1-1
-16D9
I:;C6:6.85/-E.
P=@6F5 /9:;9.6.861
76 .6<9/-9
P=@6F5 1-186:51 BC
P=@6F51 76 5/6;85/-E.
P=@6F5 /9:;9.6.861
7-18=-F@-791
C6.8=579 6. 6C 1-186:5
C6.8=579 6.
/9:;9.6.861
Figura ;$E Ciclo de +ida de S%C
1.(.) *nfo!"es al est"io + esarrollo e componentes.
De los diferentes conceptos de componente , software basado en componentes
se obser+an dos grandes enfoques dominantes# uno que se centra en las
componentes mismas , trata a las cone0iones como algo que *a, que *acer- pero
que es de segunda importancia- , otro que se concentra en la interaccin entre
componentes- traba1ando en lo que se llama conectores$
4mbos enfoques resultan complementarios , cada uno es )til para ciertos
procesos asociados con el S%C$ !or e1emplo- al orientarse a las componentes se
detalla la definicin de sus estructuras , estndares para crear componentes
aceptables en un conte0to dadoI al centrarse en la interaccin se *acen e+identes
limitaciones , problemas de las aplicaciones basadas en componentes- deri+adas
de la poca comprensin de los fenmenos deri+ados de la composicin de
componentes$
<&
(l grupo que sigue el enfoque en componentes es- sin duda- ma,oritario- lo cual
probablemente se deba a que es ms fcil tratar con unidades que con grupos de
ellas$ Ftra posible causa se deri+a de pre1uicios de programacin- que ignoran
muc*as formas de interaccin- limitndose a lo que los lengua1es ofrecen
e0plcitamente- fundamentalmente el mecanismo de llamada$
4quellos que se enfocan en los conectores son pocos , se encuentran
principalmente entre los estudiosos de las arquitecturas de software- como Garlan-
S*aw- 4llen- @enad- Ta,lor , Med+ido+ic$
Los seguidores del enfoque en componentes no se preocupan muc*o de los
problemas de cone0in o interaccin- suponiendo que se pueden resol+er a tra+2s
de las propias componentes o bien por software de pegamento- representado por
software intermediario$ 4s- el enfoque puede subdi+idirse en dos +ariantes# el
estudio de las componentes per se , el estudio de aquellas en tanto estn
conformes a las reglas propuestas por los fabricantes de alg)n software
intermediario- como D@4 de Microsoft- la plataforma Ja+a de Sun o los deri+ados
de estndares CF9%4 de la FMG$
4*< M"de)"s d"#inantes
(l mercado de componentes se est desarrollando fuertemente alrededor de unos
cuantos modelos$ Cada uno de 2stos se cubre ba1o una plataforma de software
intermedio que tpicamente se orienta a sistemas distribuidos- aunque soportan
tambi2n las aplicaciones en un solo equipo$ Cada plataforma brinda un enfoque de
construccin de aplicaciones en torno a una arquitectura estndar$ %sicamente-
las plataformas que dominan el panorama son tres# D@4 de Microsoft- la
plataforma Ja+a & de Sun , CF9%4 del Fb1ect Management Group .FMG/$ La
primera representa un enfoque independiente de lengua1es de implementacin-
dependiendo fuertemente de un sistema operati+o , una serie de tecnologas
complementariasI el segundo es independiente de la plataforma bsica- pero
depende del lengua1e de implementacin .Ja+a/I el tercero pretende ser
independiente- tanto de lengua1es como de plataformas$
(n los tres casos *a, un fuerte traba1o de desarrollo de su software intermedio ,
lle+a asociado un modelo de componente , una arquitectura general recomendada
para aplicaciones de tres o ms ni+eles$
La Figura ;$= muestra una arquitectura de tres ni+eles en forma grfica$ 4)n
cuando no es una descripcin formales mu, com)n , a,uda a entender el
concepto de ni+eles$ (n la figura se separan tres partes de la aplicacin# el cliente
o ni+el de presentacin al usuario- un ni+el intermedio dedicado a la lgica de
negocios .particular a cada tipo de aplicaciones/- llamado a +eces ni+el de
middleware- , un tercero dedicado a ser+icios de datos de tipo gen2rico- capa de
atender a di+ersos clientes , ni+eles de negocios$ Los tres ni+eles pueden residir
en di+ersos equipos$ 4lgunos autores- como ?Jerum , Sims- &'''A- di+iden el
ni+el intermedio en dos secciones# una de traba1o- donde se preparan procesos ,
<<
se alistan solicitudes , otro donde residen propiamente los componentes de
negocios$ (n la primera parte se accede a recursos propios del cliente- como
bases de datos- que a,udan en los traba1os preliminares$
4)n cuando a +eces se *abla de ms ni+eles- resulta poco )til en la +isualiacin
de los sistemas- por lo cual- sin perder generalidad- se de1ar en tres para fines de
este traba1o$
/C-6.86
/9:;9.6.86 76
.6<9/-91
/9:;9.6.86 76
.6<9/-91
=6/@=19
C9/
5C
N-G6C 76
@1@5=-9 9
/C-6.86
N-G6C 76 CE<-/5 76
.6<9/-91
N-G6C 76
=6/@=191
Figura ;$= 4rquitectura de tres ni+eles$
(n esta seccin se presentan las tres plataformas con 2nfasis en su modelo de
componentes , la manera de conectarlos$ Tambi2n se presenta la arquitectura
general recomendada por cada una$ Como se +er- las tres plataformas tienden a
con+erger en elementos comunes , cuentan con puentes para conectarse con los
dems$ Se presentan en el orden en que *an aparecido , se dar ma,or 2nfasis al
modelo Ja+a por ser el que se emplea en este traba1o$
1.).1 ,lataforma &-A e Microsoft
Microsoft *a centrado muc*os de sus esfueros en la plataforma que descansa
sobre el sistema operati+o Cindows$ Ligado a ella- se gener el modelo FL(
.Fb1ect Lin7ing and (mbedding/ para crear documentos compuestos$ Con el 20ito
de 8isual %asic se generaron componentes para interfa- llamadas a*ora 4cti+e[$
!ara resol+er problemas con estos a+ances se formul el modelo CFM
.Component Fb1ect Model/ , luego se modific para soportar distribucin .DCFM/$
Ms tarde se le inclu,eron capacidades de mane1o de transacciones- mensa1era ,
mane1o de colas$ 4ctualmente se *a reformulado todo su desarrollo de
<B
componentes en torno a D@4 .Distributed inter@et 4pplications 4rc*itecture/$ _sta-
al igual que los modelos que se tratarn en las otras secciones- siguen a grandes
rasgos un modelo de sistemas distribuidos con +arios ni+eles- operando sobre la
idea de ser+idores centrales , clientes mu, ligeros comunicndose posiblemente
por 5nternet$
4*<*4*4 Tecn")"g0as 3ue $"r#an )a !)ata$"r#a DNA
D@4- abre+iatura para Distributed inter@et 4pplications- es un con1unto de
tecnologas orientadas a potenciar la creacin de aplicaciones distribuidas de tres
o ms ni+eles$ Se orienta a lograr cinco ob1eti+os#
i$ 4utonoma# permitir que las aplicaciones en ser+idores de los )ltimos
ni+eles sean realmente independientes de intromisin de los clientes-
permiti2ndoles as cuidar de recursos crticos$
ii$ Confiabilidad- entendida como la *abilidad de una aplicacin de pro+eer
resultados precisos$
iii$ Disponibilidad- entendida como el tiempo durante el cual ofrece ser+icio
confiable$
i+$ (scalabilidad- considerada como la cercana a cambio lineal en
rendimiento ante cambios en el +olumen de recursos aplicados$
+$ 5nteroperabilidad- entendida como la capacidad de una aplicacin de
acceder a datos- aplicaciones , recursos de otras plataformas$
D@4 surge ligada al sistema operati+o Cindows &'''- agrupando , me1orando
di+ersos esfueros que se *an desarrollado ligados a Cindows @T , Cindows :=$
(l logro de la autonoma se pretende conseguir aislando los ser+icios de datos de
los clientesI 2stos tendrn que solicitar ser+icios a tra+2s de requisiciones que les
a,udarn a completar los llamados (misarios .un tipo de componente/I al estar
lista una requisicin- se en+a a una componente confiable .aunque no se dice
como asegurar la confiabilidad/ llamada (1ecutante- que estar tpicamente en el
ni+el de negocios , que ser la que interact)e con los ser+icios de datos$
La confiabilidad se pretende alcanar integrando la tecnologa de mane1o de
transacciones que originalmente se conoca como MTS .Microsoft Transaction
Ser+ice/ , que a*ora se *a integrado en CFMX$
La disponibilidad , la escalabilidad sern respaldadas por el uso de mensa1es ,
colas de ellos- para lograr cierta independencia en cuanto a sincrona$ (ste
mane1o se conoce como Microsoft Message ùeue Ser+ice .MSM`/$
!ara el logro de la interoperabilidad se propone el uso de FL( D% para acceso
uni+ersal a datos- a ni+el ba1oI DCFM para crear ob1etos de datos , lograr acceso
a 3ni0 , M8S .Multiple 8irtual Storage s,stems/$ Tambi2n se emplearn el
integrador de transacciones CFMT5- [ML , otras tecnologas$ Tambi2n se
inclu,en puentes para la plataforma Ja+a , para CF9%4$
<>
La arquitectura D@4 comprende tres grupos de componentes#
o 4cti+e[ que se emplea para crear clientes con interfaces +isuales-
descansando sobre CFMI
o 4cti+e Ser+er !ages .4S!/ que operan en ser+idores de 5nternet-
creando pginas al tiempo de e1ecucin- ,
o Componentes MTS .Microsoft Transaction Ser+er/ para traba1ar en el
lado de ser+idores de aplicaciones$
Los 4cti+e[ , las 4S! descansan sobre el modelo original CFM- mientras los
otros corresponden a la e0tensin CFMX- que se describe a continuacin$
4*<*4*5 M"de)" de c"#!"nente COM=
(l modelo CFM .Component Fb1ect Model/ fue creado por Microsoft para resol+er
problemas de construccin de documentos compuestos usando FL($ Desde
entonces se *a desarrollado para permitir la construccin de aplicaciones a partir
de componentes separadas$ 4ctualmente se usa su modelo en mu, diferentes
aplicaciones- usando 8isual %asic- 8isual CXX , 8isual JXX$ Dado el predominio
del ambiente Cindows- el modelo CFM resulta uno de los ms importantes- si no
el principal- seg)n sus partidarios$ La informacin que sigue es un resumen de sus
aspectos ms rele+antes para el presente traba1o- tomadas de ?9ogerson- ;::EA-
?Urieger , 4dler- ;::=A , ?Gra,- ;::=A$
CFM ofrece un m2todo para organiar software- a)n sin usar CindowsI especifica
cmo construir componentes que pueden intercambiarse dinmicamente , ofrece
una arquitectura estndar para componentes ba1o Cindows$ La e0tensin DCFM
pro+ee lo necesario para comunicar componentes sobre una red$ CFM es neutral
frente a los lengua1es , e0pone propiedades- m2todos , e+entos$
C"nce!t" de c"#!"nente*
!ara el modelo CFM un componente es una parte de un sistema- similar a una
miniaplicacin- que +iene lista para usarse ?9ogerson- ;::EA$ Ftra forma de +erlo
es como un mdulo escrito para mane1ar un tipo particular de informacin o un
proceso particular ?Cindows- &'''A$
!ara que pueda emplearse un componente se requiere una *erramienta que
especifique la manera de crear componentes , de armar aplicaciones$ (sto lo
inclu,e CFM en sus bibliotecas de tipos- que contienen metadatos acerca de las
componentes , mecanismos para su instanciacin$
(n las bibliotecas de tipos se mane1an dos interfaces# 5T,peLib e 5T,pe5nfo$ Se
pueden emplear cinco tipos de informacin#
H CoClass# metadescriptor de ob1eto CFM , sus interfaces$
H 5nterface# mapa de memoria para operaciones p)blicas$
H Module# describe mdulo DLL$
H T,pedef# metadescriptor para estructuras definidas por el usuario$
<D
H 5mportlib# metadescriptores de elementos referidos por la componente$
Los componentes deben poder ligarse dinmicamente , encapsular su
implementacin- de modo que puedan modificarse al tiempo de correr sin afectar a
la aplicacin$ Seg)n Microsoft- con+iene esconder el lengua1e en que se desarroll
el componente para reducir dependencias , debiera poder localiarse en redes- en
forma transparente$
(0isten tres opciones de uso de componentes- que ofrecen di+ersos beneficios a
los desarrolladores#
H 4daptacin al cliente# los componentes pueden usarse para adecuar parte
de la aplicacin a las costumbres del usuario- siempre que utilicen una
misma interfa$ (n este caso puede tratarse de componentes discretos-
aislados- como pueden ser editores u *o1as de clculo$
H %ibliotecas de componentes$ (stos permiten desarrollo rpido de
aplicaciones como si se tratara de un mecano de software$ (sto se *a
empleado muc*o en aplicaciones grficas$
H Componentes distribuidas$ (l componente deseado puede encontrarse en
otra mquina- sir+iendo para crear aplicaciones distribuidas$
Inter$aces*
Dentro de una arquitectura- adems de los componentes- debe especificarse la
forma de interaccin entre ellos$ Tal +e sea la parte ms importante$ (n el modelo
CFMVDCFM la forma de comunicar un componente con otro , con la aplicacin se
logra a tra+2s de interfaces$ Microsoft eligi que 2stas sean estructuras de datos
en memoria- por lo cual a +eces se le llama aestndar binarioa$ (stas estructuras
son arreglos de apuntadores a funciones que implementa el componente$ Todo el
acceso se realia a tra+2s del apuntador al componente , no se permite usar los
elementos interiores$ (n la Figura ;$: se muestra el esquema de la interfa de
componente$
A;@.8579= 5
-.86=>5?
A;@.8579= 5 85FC5 V
5891 -.86=.91
I.86=>5? A@6=H
A77R6>
R6C6516
O8=91 :I89791
Figura ;$:$ 5nterfa en CFM .adaptada de ?Gra,- ;::=A/$
3na interfa que solamente contiene las primeras tres lneas .ùer, interface-
4dd9ef , 9elease/ es la llamada 53n7nown- de la cual *eredan todas las dems$
<E
(l mecanismo en s parece sencillo- pero se complica por el uso de di+ersos
protocolos , otras estructuras comple1as para el paso de datos ?Gra,- ;::=A$
Cada +e que se accede a un componente- se incrementa el contador de
referencias- ,a que pueden ser compartidas$ 4l liberarlo se decrementa
automticamente su contador$
4 tra+2s de la interfa 53n7nown- usando la funcin ùer,interface- se puede
interrogar al componente para obtener otras interfaces$
Creacin de instancias*
!ara crear una instancia de un componente se cuenta con un mecanismo de
Factor, que los crea , de+uel+e el apuntador correspondiente$ (ste m2todo es
cmodo en los usos ms sencillos pero poco fle0ible , falto de control en otros-
para modificar alg)n elemento antes de su instanciacin$ Si se necesita ma,or
control se emplea una interfa a la clase Factor, asociada con el componente .*a,
una para cada componente registrado/ , se manipula la instanciacin a tra+2s de
ella$
Reuti)i'acin*
Como se di1o antes- CFM no soporta *erencia de implementacin- pero s de
interfa$ 4s- para emplear los componentes que ofrece se pueden emplear los
m2todos de 4gregacin , Contencin .delegacin/$ Cada forma tiene sus +enta1as
particulares , sus defensores insisten en que la +enta1a frente al mecanismo de
*erencia es la independencia respecto al implementador de la clase base$ 4l no
depender de su implementacin- no sufre por los cambios que aquel realice en sus
componentes$
Ser&ici"s*
Con la e0tensin DCFM el modelo ofrece comunicacin +a 9!C- ser+icios de
directorio , nomenclatura- seguridad- mane1o de transacciones , administracin
del sistema$ Tambi2n cuenta con transparencia de localidad$
4l e0tenderse el modelo al actual CFMX- identificado a +eces simplemente como
CFM- se agregaron +arios ser+icios que a*ora quedan integrados en ese
ambiente$ (stos ser+icios inclu,en#
H carcter transaccional de los componentes
H ser+icios de seguridad integrados
H autodescripcin de los componentes
H mensa1era asncrona- pudiendo guardar componentes en lneas de espera
H reutiliacin de componentes , ligas a recursos .bases de datos- soc7ets-
etc$/
H soporte de *ilos de e1ecucin
H mane1o de e+entos .suscripcin , publicacin/
<=
H aislamiento de procesos asociados con paquetes- para aislar de cadas en
otros componentes$
Dentro del modelo se tiene que los componentes transaccionales que tienen
acceso a los recursos del ni+el de recursos- deben ser mu, seguras- para e+itar
problemas potenciales$ 4 estos componentes se les llama e1ecutantes , se les
considera componentes seguras$ !ara que los clientes tengan acceso a ellas se
requiere el au0ilio de un componente emisario- que se encarga de preparar la
llamada al e1ecutante- asegurndose no falte ning)n dato rele+ante$ Los emisarios
tienen acceso a bases de datos locales relati+as al cliente- mismas que pueden
emplearse en la preparacin de la solicitud$
!ara el mane1o de entidades de datos- D@4 cuenta con 4cti+e Data Fb1ects ,
Collaboration Data Fb1ects- los cuales descansan sobre t2cnicas de FL(6D% ,
FD%C- que les dan acceso a gran n)mero de bases de datos de di+ersos
pro+eedores$
4*<*4*: Ar3uitectura genera) rec"#endada
(n general- el uso de componentes en D@4 se puede dar en +arias arquitecturas-
pero quedan enmarcadas en los sistemas de ni+eles$ (l caso ms general es de
sistemas de n6ni+eles- correspondiendo a sistemas distribuidos$ La arquitectura
general es as mu, similar a la descrita al inicio de la seccin$
(l ambiente CFMX , otras tecnologas de D@4 no integradas en CFM constitu,en
el ambiente de traba1o de los componentes$
1.).2 ,lataforma .ava 2 e /"n.
Ja+a es un lengua1e orientado a ob1etos- dise"ado para ser independiente de la
plataforma- ,a que se traduce a un cdigo intermedio .b,tecode/ que se interpreta
en la llamada Ja+a 8irtual Mac*ine$ _sta se encarga- adems- de la carga de
clases en arc*i+os diferentes- la llamada a clases remotas , la +erificacin de
seguridad- que consiste en +erificar el cumplimiento de una serie de suposiciones-
entre las cuales se pueden citar# que el cdigo no e0ceda los lmites que le
corresponden , que los tipos de los parmetros coincidan con los esperados de
acuerdo con la definicin de la clase$
4l mismo tiempo- Ja+a ofrece una serie de elementos que +an ms all de un
mero lengua1e- constitu,endo toda una plataforma de desarrollo$ !arte de ella es
el soporte para sistemas distribuidos- que inicialmente cont con el mecanismo de
in+ocacin remota de m2todos .9M5/- que permita e1ecutar m2todos en clases
remotas en forma similar a las clases residentes en el mismo espacio de
direcciones- con el soporte de un sistema de control de nombres$ Ms adelante se
desarrollaron los llamados Ja+a%eans- que son componentes de granularidad
peque"a a mediana- que permiten construir interfaces , peque"os procesos , que
pueden desplegarse independientemente$ Finalmente se desarrollaron los
<:
(nterprise Ja+a%eans o (J%- que son componentes para el lado del ser+idor ,
permiten construir sistemas de +arios ni+eles$
(n esta seccin se tratarn los principales elementos de la plataforma Ja+a en su
+ersin &- en lo relacionado con componentes$
4*<*5*4 Tecn")"g0as 3ue $"r#an )a !)ata$"r#a >a&a 5 !ara e#!resas
La compa"a S3@- desarrolladora de Ja+a- distingue tres ni+eles o ediciones de
su plataforma# micro .J&M(/- estndar .J&S(/ , de empresa .J&((/$ Cada uno
inclu,e los ser+icios del anterior$ Los componentes (J% corresponden al tercero ,
es el que se tratar en 2sta , las subsecciones siguientes- llamndola
simplemente
!lataforma Ja+a &$
3na caracterstica importante de esta plataforma es que ofrece principalmente una
especificacin- que puede ser implementada por diferentes pro+eedores ba1o
reglas comunes$ (so da al usuario una gran independencia de los pro+eedores$
4dems proporciona una implementacin particular que sir+e como referencia$
(sta independencia de un pro+eedor- 1unto a la independencia de *ardware
*eredada de la definicin original de la mquina +irtual Ja+a- dan a los productos
desarrollados ba1o esta plataforma una gran transportabilidad$
Las diferentes tecnologas se organian en diferentes 4!5s que pueden
incorporarse seg)n las necesidades del desarrollador$ 4lgunas +ienen fuertemente
ligadas con la plataforma- mientras otras a)n son independientes$
3n elemento com)n a las diferentes 4!5s de la plataforma J&(( es la b)squeda
de independencia frente a productos de +endedores particulares- ofreciendo
fle0ibilidad para adecuarse a +arios de ellos , ocultando as los detalles de
di+ersos protocolos$
4lgunas de las tecnologas integradas en la plataforma J&(( son#
o Componentes de empresa .(J%/ componentes para el ser+idor en
sistemas de empresa$ Se amplan adelante$
o Ser+icio de directorio .nombres/ .J@D5/ Ser+icio de localiacin de
componentes , recursos independiente de pro+eedores- funcionando
con sistema de arc*i+os local- LD4! , @DS>- entre otros$
o Comunicacin entre procesos .9M5 , 9M5655F!/$ !rotocolos de
comunicacin entre procesos- en un mismo equipo o remotos$ %ase de
comunicacin para los componentes (J%$ La +ersin 55F! permite
compatibilidad con CF9%4$
o Transacciones .JT4/$ (sta 4!5 se emplea para acceso transaccional a
datos$ 4lgunos subsistemas complementarios .JTS/ a)n no estn
integrados en esta plataforma$
> LD4!# Lig*tweig*t Director, 4ccess !rotocolI @DS# @etwor7 Director, S,stem$
B'
o 5mplementacin para CF9%4 .Ja+a 5DL/$ Si se desea compatibilidad
con CF9%4 ms all del protocolo de comunicacin$
o Ser+lets$ (stos son componentes dedicados a interaccin de una sola
llamada con una sola respuesta- de utilidad para responder a browsers ,
otros clientes$ !ueden ser+ir como puente a otros componentes$
o Ja+a Ser+er !ages .JS!/$ Son pginas que se crean dinmicamente
ba1o solicitud de alg)n browser$ @o tienen que ser )nicamente Ja+a-
sino que inclu,e JTML , [ML$ Se compilan a ser+lets$
4)n cuando no estn integradas- las siguientes tecnologas son de rele+ancia para
aplicaciones de industria#
o 4cceso a bases de datos .JD%C/$ (sta permite acceso a bases de datos
en forma similar al FD%C- inclu,endo consultas en S`L$
o Mensa1era asncrona .JMS/$ (sta 4!5 permitir el mane1o de
mensa1era independientemente del pro+eedor del ser+icio bsico-
inclu,endo mensa1es transaccionales$
o [ML$ (ste nue+o lengua1e para comunicaciones en red tambi2n es
empleado como descriptor de los (J% , en guiones para JS!$
!or )ltimo- a futuro la plataforma incluir los llamados
o Conectores$ (stos sern puentes especficos a sistemas de empresa
pree0istente- como algunos !lanificadores de recursos .(9!D/ o
sistemas tales como Tu0edoE$ 4)n no est concluida su especificacin$
4*<*5*5 M"de)"s de c"#!"nentes ?+eans@
(n la !lataforma Ja+a & e0isten al menos dos elementos considerados
componentes# los Ja+a%eans , los (nterprise Ja+a%eans o (J%$ Los primeros se
orientan ms a construccin de interfaces- clientes , aplicaciones peque"as sin
necesidad de mane1o transaccional o *allarse distribuidos- mientras los segundos
se enfocan a necesidades de empresa- especialmente en ambientes distribuidos-
donde se utilia proceso de transacciones$
>a&a+eans
Ja+a%eans es la interfa de aplicaciones .4!5/ que define el modelo de
componente de software para el lengua1e Ja+a$ (n esta seccin se describen
algunas de sus caractersticas- tomadas principalmente de ?S3@- ;::EA , ?Urieger
, 4dler- ;::=A$
Concepto de componente$
3n Ja+a%ean- o %ean- es un componente reutiliable escrito en Ja+a$ !or
componente se considera una amplia +ariedad de unidades- que +an desde
D (9!# (nterprise 9esource !lanner$
E T3[(DF es un producto de %(4$ !uede consultarse la pgina
*ttp#VVwww$beas,s$comVproductsVtu0edoVinde0$s*tml$
B;
bloques sencillos que deben integrarse en una aplicacin *asta aplicaciones
completas que pueden traba1ar autnomas- componerse en una aplicacin o en un
documento=$
(stos componentes pueden combinarse manualmente o empleando di+ersas
*erramientas- tales como editores de documentos- scripts , *erramientas +isuales
para armar aplicaciones$
!ara ser aceptable como %ean- un componente escrito en Ja+a debe soportar#
a/ 5ntrospeccin$ Jabilidad de informar sus caractersticas a tra+2s de una
interfa$
b/ 4daptacin al cliente$ !uede modificarse empleando mecanismos de
*erencia para adecuar apariencia , comportamiento$
c/ Soporte de propiedades$ Cuenta al menos con funciones estndar para leer
o escribir +alores de ellas-
d/ Soporte de e+entos$ Los componentes deben poder acti+arse a tra+2s de
e+entos- empleando aescuc*asa$
e/ !ersistencia$ Sus especialiaciones pueden sal+arse , recuperarse$
(l mecanismo de introspeccin informa acerca de las propiedades- e+entos ,
m2todos que soporta un componente$
Se espera que la ma,ora de los Ja+a%eans sean peque"os o medianos$ Se *abla
de %eans +isibles- como botones , otros elementos grficos- e in+isibles- si
carecen de partes grficas , realian funciones internas- tales como acceso a
bases de datos$
Como au0iliar de desarrollo de los Ja+a%eans se definen una serie de
con+enciones- denominadas por S3@ apatrones de dise"oa:- que no son
obligatorios pero s recomendados para facilitar el uso del componente en la
*erramienta constructora$ 3no de ellos permite generar automticamente
funciones para consultar .Get[ e 5s[/ , modificar .Set[/ cualquier propiedad del
componente$
Los Ja+a%eans se empacan en arc*i+os de tipo J49- ane0ando un descriptor-
denominado manifiesto- que describe los elementos contenidos en el arc*i+o$ 4l
tiempo de despliegue la *erramienta que los ensambla o el contenedor donde se
e1ecutan puede cargar %eans de di+ersos paquetes- usando sus descriptores$
(l ambiente donde se e1ecutan los Ja+a%eans pro+ee facilidades para conectarlos
dinmicamente- inclu,endo la compilacin de adaptadores cuando es necesario$
= !or documento o documento compuesto se entiende un contenedor unificado de datos
compartibles , los mecanismos que lo asocian con di+ersas aplicaciones , permiten a 2stas crearlo
, mantenerlo$ (l documento aparece integrado funcionalmente con la aplicacin ?4dler- ;::>A$
: (strictamente- no son patrones de dise"o en el sentido corriente del t2rminoI ms bien son
con+enciones de nomenclatura que facilitan el traba1o de las *erramientas de ensamble de
aplicaciones$
B&
3n elemento importante para el mane1o de Ja+a%eans , aplicaciones formadas
con ellos es la serialiacin- mediante la cual un %ean o parte de 2l se *ace
persistente en memoria secundaria$ La serialiacin puede mane1arse
automticamente si todos los elementos son serialiables- es decir- si no *a,
recursos no serialiables como arc*i+os o soc7ets abiertos$ De otro modo el %ean
tendr que proporcionar m2todos para serialiar tales recursos$
Todos los %eans desplegados en un contenedor se e1ecutan en un mismo
proceso- por lo cual estn su1etos a problemas colecti+os en caso de falla de la
aplicacin$ Sin embargo- pueden utiliar el mane1o de *ilos disponible para Ja+a-
el cual les permite mantener interfaces interacti+as mientras otros %eans procesan
datos internamente$
Ser+icios$
(l modelo ofrece +arios ser+icios- que inclu,en#
H Comunicacin remota- +a 9emote Met*od 5n+ocation .9M5/ sobre TC!V5!$
H Directorio , nomenclatura$
H Seguridad- que inclu,e uso de lla+e p)blica , pri+ada$
H 4dministracin$
H Transacciones- basado en modelo de FMG$
4dems se pueden empacar en contenedores para ligarse a componentes
basadas en el modelo CFM de Microsoft- mediante los denominados apuentesa$
4s- por e1emplo- se pueden ligar 4cti+e[ con Ja+a%eans$
Enter!rise >a&a+eans ?E>+@
!ara el ni+el intermedio en arquitecturas de tres ni+eles se emplea un tipo de
componente diferente a los Ja+a%eans- denominados (nterprise Ja+a%eans
.(J%/- (stos se orientan a la lgica de negocios- encargndose de ser
intermediarios entre recursos , clientes$ La informacin para esta seccin se tom
principalmente de la especificacin de (nterprise Ja+a%eans ;$; ?S3@- ;:::A , de
?9oman- ;:::A$
Los (J% incorporan tecnologas de mane1o de transacciones , mane1o de
nombres- concurrencia- persistencia , seguridad- necesarias para implementar
aplicaciones distribuidas$
Los (J% residen necesariamente en contenedores- los cuales a su +e residen en
ser+idores$ (l contenedor se encarga de casi todas las tareas de soporte-
inclu,endo la seguridad- la transaccionalidad , los nombres$ 4lgunos aspectos
pueden o no ser delegados al contenedor- como el caso de la persistencia$
4dems el contenedor es el )nico autoriado para comunicarse con los
componentes que *a,an sido desplegados en el mismo$ Los clientes slo pueden
comunicarse a tra+2s de ser+icios que les ofrecen +a el contenedor$
B<
Cualquier (J% tiene tres interfaces- de las cuales las dos primeras son bsicas#
o 2"#e inter$ace- que lo representa ,
o re#"te inter$ace- que ofrece la funcionalidad propia del (J%
o #etadata inter$ace$
La interfa KJomeL permite las siguientes acciones#
H localiar un (J% usando ser+icio de nombres J@D5
H crear instancias del (J%
H destruir instancias del (J%
La interfa K9emoteL es la interfa que ofrece la funcionalidad propia del (J%$ (l
contenedor se responsabilia de crear una clase que la implementa , que delega
sus acciones en el propio (J%$ (sta interfa se obtienen una +e localiado el (J%
de inter2s , creada una instancia del mismo$
La interfa KmetadataL informa acerca de las caractersticas del (J% , es de
utilidad en el caso de in+ocacin dinmica- cuando se debe conocer la naturalea
del (J%- ignorada al tiempo de despliegue$
Cada (J% se empaca en un paquete contenido en un arc*i+o e1b61ar- que contiene
la clase , las interfaces Jome , 9emote- as como un descriptor escrito en [ML$
Los (J% pueden ser de dos tipos#
o de sesin
o de entidad
Todos los (J% tienen una identidad- pero solamente es p)blica en el caso de los
(J% de entidad- siendo 2sta su lla+e$
(J% de sesin$
(ste tipo de (J% se e1ecuta a nombre del cliente .que puede ser otro (J%/ ,
operan como una e0tensin del mismo$ !ueden representar un comportamiento
transaccional$ @o representan datos compartidos directamente- pero pueden
acceder a ellos , actualiarlos$ Su +ida est asociada a la del cliente , no son
persistentes en general- por lo cual una falla del contenedor los pierde$
Los (J% de sesin pueden tener estado o no$ Los primeros se asignan a un cliente
)nico- mientras los segundos son compartidos por +arios- debiendo cuidarse de
problemas de concurrencia$ Cuando tiene estado se le llama estado
con+ersacional- e inclu,e todos sus +alores de instancias ms la cerradura
transiti+a de todas sus referencias- ms los recursos abiertos- los cuales no son
serialiables$
Los (J% sin estado se usan de un con1unto compartido .pool/- mane1ado por el
contenedor$ Son )tiles para reducir costo de demasiados (J% , de tiempos de
BB
creacin , remocin- pero al costo de no conocer si cambi el %ean entre dos
in+ocaciones sucesi+as a sus m2todos$
La transaccionalidad puede ser mane1ada directamente por el (J%- por el
contenedor o por el cliente que lo in+oc$ Cada forma tiene sus +enta1as ,
des+enta1as- pero de1arla en manos del contenedor es la ms simple$
(J% de entidad$
!ara el mane1o de datos compartidos- persistentes- se emplean los (J% de
entidad$ _stos poseen un estado , una lla+e )nica accesible a los clientes$ (n este
tipo de (J% es mu, importante el 0anle que los representa- que puede
obtenerse- serialiarse , emplearse ms tarde para referirse al mismo ob1eto de
datos$
!or el consumo de recursos necesarios para cada (J%- no se recomienda crear
(J% de entidad para ob1etos dependientes de otro- ,a que de esta manera se
consumen ms recursos innecesariamente- ,a que- al ser dependientes- al
desaparecer el primero desaparece el segundo$
La persistencia puede mane1arla el propio %ean o el contenedor$
Uti)i'acin de E>+*
(l creador de un (J% pro+ee un paquete con la clase , las interfaces Jome ,
9emote$ (ste (J% debe ser dado de alta en un contenedor- donde quedar
residente , podr ser localiado a tra+2s de ser+icios J@D5 del propio contenedor$
3na +e dado de alta un (J%- los clientes .(J% u otros elementos de Ja+a/
localian un (J% buscando su interfa JomeI a tra+2s de ella obtienen una clase
pro0i que les da acceso a la interfa remota del (J%$
Ser&)ets
Las ser+lets son peque"as aplicaciones o componentes que realian una sola
funcin- como se ilustra en la figura ;$;'- , que no se reinician cada +e que son
in+ocadas- sino que se acti+an de un banco de recursos$ 4l igual que los
Ja+a%eans , los (J% requieren un contenedor que se encarga de su
administracinI en este caso se denomina Ser+let (ngine , reside usualmente en
un ser+idor Ceb$ Las ser+lets pueden ser in+ocadas desde un browser o desde
otra ser+let$ !or su naturalea no guardan estado entre llamadas sucesi+as$ Se les
usa para funciones relacionadas con la interfa de usuario , tambi2n como enlace
con otros componentes$ 9epresentan una alternati+a a las applets que se
embeben en las pginas Ceb$
B>
Figura ;$;' Funcionamiento de una ser+let
4*<*5*: Ar3uitectura genera) rec"#endada
La arquitectura general que se propone para aplicaciones basadas en (J% es del
tipo de ni+eles que se present en la introduccin de esta seccin$ (n la figura
;$;; se muestra un diagrama tpico#
BJ S-18.
C6<5791
/C-6.86
/C-6.86
S6=G-79= #6F
EJB
EJB
S6=G-79= EJB
/9.86.679=
Figura ;$;; 4rquitectura tpica de sistema basado en (J%$
1.).( CO1BA el OM2.
(l FMG .Fb1ect Management Group/ es una organiacin a la que concurren
di+ersas compa"as desarrolladoras de software- que produce estndares
industriales en di+ersas tecnologas- principalmente de software orientado a
ob1etos- tales como 3ML , CF9%4$
(l FMG *a desarrollado una arquitectura para el mane1o de ob1etos
interoperables- denominada FM4 .Fb1ect Management 4rc*itecture/- sobre la cual
se desarroll el modelo CF9%4- que permite construir implementaciones
compatibles de intermediarios .bro7ers/ que facilitan el desarrollo de aplicaciones
distribuidas con transparencia de la localiacin de los ob1etos$ (ste enfoque es
independiente de las di+ersas plataformas , de los distintos lengua1es que se
puedan emplear en el desarrollo de software- por lo cual resulta ms general que
DCFM o Ja+a$ 4unque los ob1etos que mane1a CF9%4 puedan considerarse
componentes- no resulta completamente aceptable para los desarrolladores- por lo
cual se encuentra en proceso de definicin lo que se entender por Componente
CF9%4 ?FMG- ;::EAI esta solicitud requiere que las propuestas consideren un
mapeo con Ja+a %eans- de modo que una componente CF9%4 pueda ser
Ser+let
;$ lee datos <$ emite respuesta
&$ realia algo
BD
identificada con un Ja+a %ean$ (ntre las respuestas recibidas e0iste una
propuesta con1unta de +arias compa"as que resulta similar a (nterprise
Ja+a%eans- pero con +enta1as de CF9%4$ Dic*a propuesta est documentada en
?%(4- ;::EA$
(n esta seccin se describen algunos elementos de CF9%4 , de una propuesta
de componentes CF9%4$ La primera parte tomada principalmente de ?FMG-
;::EA- ?9ogerson- ;::EA , ?!ope- ;::=A- con elementos de ?Siegel- J$- ;::DA-
?Frfali , Jar7e,- ;::EA , ?Urieger , 4dler- ;::=A$
4*<*:*4 Ar3uitectura COR+A
Modelo bsico de ob1etos$
(l modelo bsico define todos los conceptos orientados a ob1etos sobre los que se
constru,e CF9%4- inclu,endo ob1etos- operaciones- interfaces , tipos que no son
ob1etos$ Define la semntica com)n de las caractersticas +isibles e0ternamente
de una manera independiente de su implementacin$
3n ob1eto- para CF9%4- es una instancia de una clase que encapsula
operaciones- atributos , e0cepciones$
3n ob1eto administrado es un ob1eto su1eto a administracin , control a todo lo
anc*o del sistema- que toma una de las formas bsicas#
o 4plicacin$
o Facilidad$
o Ser+icio$
3na operacin es una accin ofrecida por un ob1eto , que se conoce por su firma$
La firma se forma por el nombre de la operacin- los parmetros de entrada , los
tipos de resultados$
3na interfa es una coleccin de firmas$
Los ob1etos son instancias de un tipo$ Los tipos son )nicos$
Como se busca la portabilidad e interoperabilidad de dise"o- no se pueden
redefinir ni reemplaar elementos del modelo- )nicamente e0tenderlo$ Las
e0tensiones que pro+een especialiaciones ms concretas se llaman
componentes$
3na e0tensin formada por el modelo bsico , un grupo de componentes forma un
perfil$ CF9%4 mismo es un perfil$
Ar3uitectura de re$erencia*
BE
La arquitectura de referencia- +er Figura ;$;&- identifica las entidades que forman
la FM4- as como las interfaces , protocolos empleados$ La entidad ms rele+ante
es el intermediario .Fb1ect 9equest %ro7er- F9%- comercialmente conocido como
CF9%4/$ (ntre las interfaces se encuentran#
o Ser+icios de ob1etos- para emplearse en cualquier programa en la
realiacin de ser+icios generales$
o Facilidades comunes- orientadas a dominios generales- orientadas al
usuario$
o 5nterfaces de dominio- especiales para dominios especficos$
o 5nterfaces de aplicacin- que inclu,e interfaces no estandariadas para
aplicaciones especficas$
Los dominios especficos se organian en forma de marcos de ob1etos- que son
colecciones de ob1etos que cooperan para ofrecer soluciones integradas , que
pueden ser particulariadas por el desarrollador$
F 9 %
5nterfaces de
aplicacin
5nterfacesde
dominio
Facilidades
comunes
Ser+icios
a ob1etos
Ser+icios
a ob1etos
Figura ;$;&$ 4rquitectura de referencia .adaptada de ?!ope- ;::=A/$
C"##"n Re3uest +r"/er Arc2itecture ?COR+A@*
(sta parte define las interfaces de programacin del F9%- que es el mecanismo
que *ace transparente la comunicacin entre ob1etos- sin importar su localiacin$
!ara definir las interfaces se emplea como estndar el Lengua1e de Definicin de
5nterfaces .5DL/$ 4dems tiene mecanismos para interoperar con diferentes F9%-
incluso algunos que no son completamente estndares$
CF9%4 ofrece di+ersos ser+icios , facilidades- cada uno de las cuales se
especifica definiendo sus interfaces en 5DL$
4*<*:*5 M"de)" de c"#!"nente ?!r"!uest"@
Desde *ace algunos a"os se *io e+idente que el modelo CF9%4 era )til a ni+el
de ob1etos- pero que en aplicaciones de empresa se necesitan grupos de ob1etos
ms que 2stos indi+idualmente$ Con el desarrollo de componentes ba1o el modelo
CFM , Ja+a%eans se tena una fuerte competencia- que *aca deseable la
B=
e0tensin de CF9%4$ 4 principios de ;::E se emiti una in+itacin para presentar
propuestas de un modelo de componentes$ 3n grupo de compa"as *io una
propuesta que es el borrador que se espera llegue a estndar- aunque no lo es
*asta la fec*a ?%(4- ;::EA$ La in+itacin especificaba que el modelo fuera
compatible con Ja+a%eans- pero la propuesta se *io compatible con (nterprise
Ja+a%eans$ Las notas que siguen corresponden a la citada propuesta , al traba1o
de ?Cang et al- &'';A$
La propuesta a que se *a *ec*o mencin define un componente como un ob1eto
CF9%4 que satisface ciertos patrones prescritos- donde tales patrones son
interfaces , notaciones programticas$
(l modelo permite a desarrolladores implementar- administrar- configurar ,
desplegar componentes que integran ser+icios como transacciones- seguridad-
estado persistente , notificacin de e+entos$
Los componentes pueden crearse a partir de un esquema .template/ o de una
instancia e0istente tomada como modelo$ Los componentes se ofrecen como un
paquete que inclu,e la clase , algunos otros artefactos- que pueden incluir una
instancia que se reinstanca al ser desempacada$
3n componente inclu,e cuatro tipos de puertos para interactuar con clientes ,
otros componentes#
H -acetas# son interfaces ofrecidas que pueden in+ocarse sncrona o
asncronamente$ @o necesariamente coinciden con las interfaces
*eredadas , que son soportadas$
H Rece!t,cu)"s# interfaces requeridas que deben satisfacerse con ser+icios
de otros componentes$
H -uentes ( su#ider"s de e&ent"s# enlaces para mane1o de e+entosI
emplea el patrn Fbser+er$
H Atribut"s# !ropiedades a las que se da accesoI se pueden poner
condiciones acerca de sus +alores o su cambio- que generan e0cepcionesI
de esa manera se puede cuidar su integridad$
Todo ello debe tener implementacin interna en el componente$
(l componente completo tiene dos interfaces importantes# la interfa Jome , la
interfa @a+igation$ 3n cliente debe localiar la interfa Jome +a un ser+icio
Jome6Finder , luego- +a un patrn Factor,- se tiene acceso al componente$
Los componentes pueden formarse de otras componentes , puede e0poner parte
de sus interfaces$ La componente que contiene a otras es responsable de su
control$
(l ensamble de aplicaciones a partir de componentes se realia generalmente por
medio de *erramientas de construccin- por lo cual las componentes se
autodescriben$ (sta autodescripcin o introspeccin- se realia por medio de
B:
interfaces especiales del paquete para poder obtener informacin sin necesidad
de instanciarla$
4l igual que los (J%- los componentes CF9%4 requieren de un contenedor para
operar- el cual es el encargado de mane1ar la comunicacin con el componente$
Los contenedores se instalan en ser+idores encargados de pro+eer di+ersos
ser+icios- tales como multiprogramacin- nombres- transacciones , balance de
carga$
$Los componentes pueden clasificarse como#
o de ser+icio- que atienden a un solo cliente mediante una )nica
in+ocacinI
o de sesin- que atienden un solo cliente , pueden tener estado o noI
o de proceso- que son compartidas por +arios clientes- sir+iendo como
depsito de procesosI
o de entidad- que son compartidas- tienen lla+e )nica , estado ,
almacenan datosI
La persistencia de un componente puede mane1arla el contenedor o bien el propio
componente$
Los componentes se preparan en un paquete- el cual lle+a un descriptor escrito en
[ML , otro descriptor que indica cmo debe ensamblarse$
1.).) Comparacin
De las bre+es descripciones presentadas se puede notar una gran similitud entre
los tres modelos presentados .+er Tabla ;$;/$
Tabla ;$; Comparacin de plataformas dominantes
C"nce!t" DNA >5EE COR+A
@aturalea !roducto Descripcin Descripcin
Frente a *ardware
, sist$ operati+o
Dependiente 5ndependiente 5ndependiente
Frente a lengua1e 5ndependiente Dependiente 5ndependiente
Control 3na compa"a 3na compa"a Muc*as
compa"as
Transacciones S S
Mensa1era S S- no integrado
Comunicacin
remota
DCFM 9M5- 55F! 55F!
Componentes
definidas
S S !endiente
Directorio S S S
Seguridad S S S
!gina Ceb 4cti+e Ser+er Ja+a Ser+er 666
>'
C"nce!t" DNA >5EE COR+A
creada en
e1ecucin
!ages !ages
Componentes de
interfa *ombremquina
4cti+e6[ Ja+a %eans 666
Cliente delgado Ser+let Componente de
ser+icio
Sesin con
estado
Sesin Componentes
e1ecutables
Componentes
MTS#
(misario
(1ecutante
Sesin sin
estado
!roceso
Componentes de
datos
Fb1eto de datos (ntidad (ntidad
Como puede +erse en la Tabla ;$;- se +a dando una con+ergencia por la misma
competencia que obliga a agregar opciones a los modelos que carecen de alguna
caracterstica$ !or su dise"o- los componentes (J% son un subcon1unto de los
componentes CF9%4 en la propuesta que se est considerando$
4*A Resu#en
(n este captulo se anali la problemtica del desarrollo de software
crecientemente comple1o- a la cual parece ofrecer solucin el software basado en
componentes$ !ara este tipo de software es necesario un modelado
arquitectnico- que se re+is$ Del S%C se analiaron sus elementos
fundamentales , las tres plataformas ms populares$
De los aspectos discutidos con+iene destacar los elementos ms rele+antes para
el desarrollo del presente traba1o- que se emplearn en los captulos < ,
siguientes#
H (l S%C es una forma- crecientemente popular- de enfrentar las necesidades
de desarrollo de software de empresa$
H La creciente comple1idad del software- en particular del S%C- *ace
necesario el uso de arquitectura de software$
H La arquitectura del software est fuertemente ligada a la estructura de los
sistemas , tiene como elementos bsicos componentes , conectores$
H !ara describir la arquitectura de un sistema se emplean lengua1es
descripti+os de arquitectura- los cuales inclu,en por lo menos componentes-
conectores- configuracin de sistemas , subsistemas , *erramientas de
soporte$
H %uscando la con+ergencia entre esfueros de arquitectura de software ,
desarrolladores- una posibilidad es crear LD4 como e0tensiones de 3ML$
>;
H La arquitectura de software enfatia el estudio de interacciones entre
componentes- mismo terreno de las pruebas de integracin- por lo cual
aquella es una buena base para 2sta$
H (l concepto de componente como elemento que se puede desplegar
independientemente para ser combinado con otros formando aplicaciones$
H Los componentes- en sentido moderno- poseen una serie de
caractersticas- entre las que destacan# encapsulamiento- reutiliacin-
interoperacin- ba1o acoplamiento- definidos a partir de interfaces ofrecidas
, requeridas- adecuacin al tiempo de despliegue- liga pospuesta ,
necesidad de contenedor$
H (n las aplicaciones formadas por componentes la interaccin se puede
modelar por medio de componentes en sentido arquitectnico$
H Ja+a & es una de las plataformas ms e0itosas del mercado de
componentes , ser la utiliada en este traba1o$
>&
Ca!0tu)" 5 Pruebas de integracin de
S"$t%are +asad" en C"#!"nentes
Con cualquier m2todo de desarrollo de software se *ace necesario el uso de
pruebas$ La necesidad surge de la propensin *umana a cometer equi+ocaciones-
que- en el caso del software- originan defectos que pueden pro+ocar fallas al
momento de e1ecucin$ 4dems de equi+ocaciones *umanas e0isten fallas del
*ardware donde el software se e1ecuta- fallas en el sistema operati+o , errores de
interaccin con los seres *umanos$ Todos estos problemas se *acen ms
e+identes en software moderno que utilia sistemas distribuidos , abiertos$
Conforme el software se torna ms comple1o- las pruebas son ms necesarias
para asegurar el cumplimiento de ciertos criterios mnimos de operabilidad , para
a,udar a garantiar la calidad del software$ 4 pesar de su importancia- las pruebas
resultan un tema mal +isto por algunos , desconocido o menospreciado por gran
parte de los desarrolladores$
(n este captulo se presentan algunos elementos bsicos para la discusin del
presente traba1o$ Se inclu,en elementos generales como marco- una seccin
dedicada a la prueba de software orientado a ob1etos- por la relacin que 2ste
tiene con el software basado en componentes ,- principalmente- elementos
especficos de prueba de componentes$
!arte del material del captulo apareci en ?Fernnde- ;::: bAI en ese traba1o se
desarrolla ms ampliamente la parte relati+a a software FF$
4 lo largo del captulo se desarrollar ms e0tensamente la parte concerniente a
pruebas de integracin- la parte ms rele+ante para este traba1o$
><
5*4 Pruebas de s"$t%are*
Cuando se desarrolla software debe +erificarse que cada parte cumpla con las
especificaciones establecidas , +alidarse el sistema contra los requerimientos del
usuario$ La +alidacin emplea un proceso de prueba del software- donde se
e1ecuta 2ste con datos especialmente seleccionados$
La prueba del software es un proceso que a +eces se confunde con la depuracin
, que muc*as +eces se descuida$ Sin embargo- es necesario para la +alidacin ,
para establecer la confiabilidad del producto ,- con ello- contribuir a su calidad$
(n esta seccin se tratar bre+emente la naturalea de la prueba- sus ob1eti+os-
sus estrategias , ni+eles$
2.1.1 -ecesia e la pr"eba el soft#are.
La necesidad de *acer pruebas tiene +arias causas generales que son mu,
difciles de eliminar$ Las tres ms sobresalientes son#
H Pr"!ensin a e3ui&"carse$ (l ser *umano es propenso a cometer
equi+ocacionesI 2stas se manifiestan en di+ersos problemas contenidos en
los modelos .defectos o faltas/ , que pueden manifestarse como fallas al
tiempo de e1ecucinI
H -a))as de 2ard%are$ La infraestructura empleada para el desarrollo de
software .*ardware- sistemas operati+os- compiladores- utileras- etc$/ no
est e0enta de fallas- lo que introduce defectos adicionales o permite que
subsistan inad+ertidos los que introdu1o el desarrolladorI
H Creati&idad de) desarr"))ad"r$ (l desarrollo de software es una labor
creati+a , por ello es com)n que el producto desarrollado no coincida con el
modelo contenido en las especificaciones$ Jorgensen ?Jorgensen- ;::>A lo
e0presa en forma de diagrama de 8enn- como en la Figura &$;$
Figura &$;$ 9elacin entre (specificacin e 5mplementacin$
De la Figura &$; se tiene- idealmente- que ambos con1untos debieran ser iguales-
pero en la prctica- lo ms que se puede lograr es que ( 5- lo que de1a espacio
para funcionalidades no pre+istas en las especificaciones$
(0isten +arias formas de asegurarse que el software no contenga defectos$ 3nas
se concentran en re+isar el software en desarrollo- en sus di+ersas etapas$ Ftras
analian productos terminados en cada una de ellas$
5 ( 5mplementacin (specificacin
>B
!ara el primer enfoque e0isten +arias t2cnicas de re+isin- que inclu,en#
re+isiones t2cnicas- wal7t*roug*s ?Manns- ;::DA e incluso re+isiones personales-
como en el caso del m2todo !S! ?Jump*re,- ;::EA$ Todas ellas *erederas del
antiguo m2todo conocido como Kprueba de escritorioL$
Las t2cnicas de re+isin permiten descubrir un alto porcenta1e de defectos en el
software- pero no la totalidad$ Su +enta1a principal radica en equipos de desarrollo
donde se tienen integradas esas labores con las de +erificacin$ Sin embargo son
poco )tiles cuando se reutilian productos pree0istentes- como bibliotecas de
funciones- bibliotecas de clases , componentes$
!ara los defectos remanentes despu2s de procesos de re+isin , para software
cu,o desarrollo no estu+o su1eto a 2l- se requieren m2todos de identificacin de
defectos a tra+2s de la e1ecucin del propio software- que son los que se conocen
como pruebas$
2.1.2 Conceptos bsicos.
La palabra KpruebaL tiene dos acepciones relacionadas#
a/ como e0perimento .test/ concreto donde se e1ecuta una piea de software , se
obser+a su comportamiento$
b/ como un proceso completo .testing/ de e1ecucin de una o ms pruebas en el
sentido anterior$
La prueba como e0perimento se concreta en un con1unto de casos de prueba que
son especificaciones de cmo realiarla- inclu,endo las condiciones de e1ecucin-
los datos de entrada , las salidas esperada$ _sta puede obtenerse manualmente o
a partir de +ersiones anteriores del sistema .regresin/$ (n ocasiones no puede
establecerse e0plcitamente la salida esperada , entonces se recurre a un orculo
.mecanismo que aprueba o rec*aa la salida obtenida/ o a un grupo de e0pertos
que obser+an el comportamiento del software$ (ste )ltimo enfoque es el ms
usado en la industria$
De acuerdo con el estndar 5(((V4@S5- el proceso de prueba se define como#
KEl proceso de operar un sistema o componente bajo condiciones
especificadas, observando o registrando los resultados y efectuando una
evaluacin de algn aspecto del sistema o componenteL ?4@S5V5(((-
;::'A$
La prueba del software se realia para satisfacer una o ambas de las metas
siguientes#
a/ +alidar directamente el producto contra sus requerimientos establecidosI
b/ encontrar defectos en el producto ,- de esta manera indirecta- contribuir
a la +alidacin , ganar confiana en el producto$
>>
4lgunos autores se conforman con la meta inicial- a)n cuando siempre puede
*aber defectos a pesar de satisfacer los requerimientos$ 4 pruebas con ese
enfoque a +eces se les llama pruebas de conformidad$
5dealmente la primera meta debiera bastar- pero ocurre que#
H Re3ueri#ient"s inc"#!)et"s# los requerimientos no son tan completos
como fuera deseable- por las limitaciones de los m2todos de recoleccin ,
por su propia dinmica$ 4s pues- sera difcil lograr un con1unto suficiente
para guiar las pruebasI
H Ca#bi"s en e) desarr"))"# los desarrolladores introducen elementos
adicionales seg)n su creati+idad$ 4 +eces tales elementos contribu,en al
logro de los propsitos del software- pero otras estorban , a)n generan
gra+es problemas$ !ara e+itar esta situacin se tendran que especificar
requerimientos Knegati+osL acerca de lo que no se desea que *aga el
software- pero 2ste con1unto es prcticamente infinito$
La ma,ora de los autores prefiere considerar las dos metas- como ?Jorgensen-
;::>A- ?Ma,r*auser- ;::'A , en el glosario de la %ritis* Computer Societ, ?%ritis*
Computer Societ,- ;::BA o incluso dar ms peso a la segunda- como ?M,ers-
;:E:A , ?%eier- ;::>A$
4l respecto- M,ers ?M,ers- ;:E:A- da algunas raones que apo,an considerar la
segunda meta#
H C"st"# las pruebas son costosas , por ello deben aportar alg)n +alor
agregadoI 2ste pro+iene de la localiacin de defectos- para corregirlosI
H En$"3ue a #etas# los desarrolladores tienden a traba1ar por metas$ Si la
meta es satisfacer los requerimientos- subconcientemente sesgarn su
traba1o buscando casos de prueba que de1en satisfec*os los
requerimientos- sin profundiar ms all$ (n cambio- si buscan defectos-
debern localiarlos , e0ponerlos- a)n los ocultos$
Dentro de las dos grandes metas indicadas se localian muc*as submetas que
representan diferentes usos de la prueba del software- dando ma,or 2nfasis a
alguno de sus aspectos$ 4s se tienen- entre otras- pruebas de rendimiento- de
regresin- de resistencia , de usabilidad$
Jasta a*ora se *a *ablado informalmente de errores- defectos- faltas , fallas-
asociadas con la prueba del software$ 3na formaliacin es la siguiente- tomada
de ?4@S5V5(((- ;::'A$
a/ e3ui&"cacin ?mista3e@# accin del ser *umano que produce un
resultado incorrecto$
b/ de$ect" o $a)ta ?fa"lt@# 3n paso- proceso o definicin de dato incorrecto
en un programa de computadora$ (l resultado de una equi+ocacin$
.!otencialmente origina una falla/$
>D
c/ $a))a ?fail"re@# resultado incorrecto- el resultado .manifestacin/ de una
falta$
d/ err"r ?error@# magnitud por la que el resultado es incorrecto$
Debe notarse que los t2rminos mencionados tienen significados mu, similares ,
algunos autores los usan meclados$ (s mu, com)n llamar error a la equi+ocacin
, a)n al defecto$
3na equi+ocacin puede generar ms de un defecto$ 3n defecto no siempre causa
una falla o bien 2sta puede no ser e+idente$ Jorgensen sugiere identificar sntomas
?Jorgensen- ;::>A que a+isan de la presencia de fallas$
!ara que un defecto origine una falla se deben presentar tres elementos- seg)n
Mic*aels ?Mic*ael , Jones- ;::DA#
a/ que se e1ecute el segmento de cdigo que contiene el defectoI
b/ que el defecto produca un cambio no deseado en el estado del software
.almacenando un resultado/I
c/ que el cambio se propague *asta alguna salida- para as poder
identificarlo$
La primera condicin est asociada con la 1ustificacin de las pruebas
estructurales- que buscan las reas no probadas por otros medios$ La tercera
1ustifica el uso de defectos artificiales para el estudio de la propagacin$
@o todos los defectos son de igual importancia o Ktama"oLI sin embargo no *a,
una forma )nica de medirlos$ %sicamente se usan dos enfoques# el sintctico-
que mide la gra+edad del defecto por su e0tensin en elementos sintcticos del
cdigo- , el semntico que mide sus efectos o magnitud del error ?Fffutt , Ja,es-
;::DA$ 3n defecto peque"o sintcticamente puede causar grandes problemas
semnticamente , +ice+ersa$ 3n defecto que no se manifiesta en las salidas
puede considerarse como de tama"o cero- semnticamente$
2.1.( 1ealizacin e las pr"ebas.
Como se mencion antes- las pruebas se concretan en casos de prueba$ (stos
casos deben comenar a prepararse en paralelo con el desarrollo del software$
!ara su uso deben solucionarse +arios problemas importantes relacionados con
tres etapas#
H preparacin de casos de pruebaI
H e1ecucin de los casos de prueba#
H decisin acerca de cundo suspender la prueba$
4 continuacin se describen las tres etapas , otros elementos que influ,en sobre
su realiacin$
>E
5*4*:*4 Pre!aracin
La preparacin de casos de prueba parte de considerar un modelo del
funcionamiento del software , un con1unto de suposiciones acerca de las faltas
posibles , su e+entual colocacin$ (stas suposiciones se concretan a +eces en
una ta0onoma de defectos .+er &$;$<$>/$
(0iste una tendencia fuerte *acia la automatiacin de la generacin de casos de
prueba ?%inder- ;::DA$
4l modelo elegido , sus suposiciones se les asocia una estrategia de prueba- que
es lo ms fcil de *allar en te0tos no especialiados$
5*4*:*5 E6ecucin
La e1ecucin de casos de prueba requiere un m2todo de seleccin de casos ,
software de apo,o que inclu,e# un controlador de pruebas .*arness- dri+ers/ ,
cabos .stubs/ para suplir las funciones que no estn presentes$
La seleccin de casos de prueba es- usualmente- de tipo aleatorio , puede
*acerse manual o automticamente- siguiendo una distribucin uniforme .todos los
casos son igualmente importantes/ o de acuerdo a un perfil operacional$ 3n perfil
operacional es una caracteriacin cuantitati+a de cmo ser usado el sistema-
distinguiendo las partes ms usadas o las ms crticas$ Ms precisamente- un
perfil ser un con1unto de alternati+as dis1untas con la probabilidad de uso que se
le asocia a cada una ?Musa- ;::<A$ 4l respecto es rele+ante el dato siguiente#
seg)n Catson ?Catson , McCabe- ;::DA- se estima que el >'b de la e1ecucin de
un programa utilia apenas el Bb del cdigo$
5*4*:*: Sus!ensin
5dealmente- si se probara el software en todas sus formas posibles- se tendra
seguridad acerca de su comportamiento$ Desgraciadamente la prueba e0*austi+a
no es factible , se deben buscar criterios para detener el proceso con cierta
seguridad$ La decisin de parar se basa en un criterio de cobertura que se aplica
en asociacin con el modelo- que indica alg)n atributo rele+ante- , una m2trica
asociada con 2l$ Cuando el +alor de la m2trica es ma,or o igual a un umbral
especificado en el criterio- se termina el proceso , se da por probado el software$
3n poco ms adelante se darn e1emplos concretos de criterios de cobertura$
(l criterio de cobertura o criterio de prueba se define como una regla o coleccin
de reglas que imponen requerimientos a un con1unto de casos de prueba$ La
cobertura mide el grado en que se satisfacen dic*as reglas$
!ara asegurarse de que los criterios de cobertura son adecuados al software que
se est probando- se emplean los a0iomas de adecuacin propuestos por (laine
Ce,u7er , que se describen ms adelante$
>=
5*:*4*< Estrategias de !rueba*
Las estrategias de prueba se agrupan- en forma mu, general- en dos grupos#
aquellas que se orientan a obser+ar el comportamiento del sistema , las que se
enfocan sobre la estructura del producto$
Las pruebas orientadas al comportamiento son llamadas de ca1a negra-
funcionales o basadas en las especificaciones$ 4lgunos m2todos de ca1a negra
son# anlisis de dominios- tablas de decisin , modelos de mquinas de estados$
Las pruebas enfocadas sobre la estructura son llamadas de ca1a blanca .o
transparente/ , basadas en la implementacin$ 4lgunos modelos de ca1a blanca
son# flu1o de control- anlisis de ciclos , mutaciones$
4mbos aspectos resultan ortogonales , complementarios ?!err, , Uaiser- ;::'A$
De *ec*o la ma,ora de los autores recomiendan emplear pruebas de ambos
grupos- cuando sea posible$
4lgunos m2todos de ca1a blanca pueden usarse ba1o el enfoque funcional , en
muc*os casos es difcil separarlos$ !or e1emplo %eier ?%eier- ;::>A considera
los modelos de flu1o de control dentro de ca1a negra$
La ma,ora de los m2todos mencionados- a e0cepcin del de mutaciones- se
orientan a localiar defectos KnaturalesL- es decir- que fueron introducidos en el
proceso de desarrollo$ Ftros m2todos introducen artificialmente defectos
conocidos para estudiar la bondad de los casos de prueba , los defectos
remanentes$ Tambi2n se usan para anlisis de sensibilidad del software frente a la
presencia de defectos$
5*:*4*A Ta8"n"#0as de de$ect"s
(n casi cincuenta a"os de prctica- se *a acumulado gran e0periencia acerca de
posibles defectos en el software- las fallas que producen , sus causas posibles$
(ste conocimiento- aunque incompleto- se puede consultar codificado en di+ersas
ta0onomas$ 4lgunas de las ms rele+antes son#
a/ La ms referenciada- de ?!urc*ase , Cinder- ;::;A$ (sta presenta una lista
de tipos de defectos- su *istoria .defecto especfico/- la falla que origina , la
posible causa o equi+ocacin original$ 3n e1emplo se muestra en la Tabla
&$;$(sta ta0onoma fue e0tendida por ?F+erbec7- ;::BA para adecuarla al
caso de software orientado a ob1etos
b/ Ftra ta0onoma popular es la de ?Firesmit*- ;::&A- que se dedica a software
orientado a ob1etos , que clasifica los defectos en seis grupos$ 3n e1emplo
se muestra en la Tabla &$&$
c/ 3na ta0onoma dedicada a seguridad pero que se aplica parcialmente a
otros usos- es la de ?Landwe*r et al- ;::<A$ 3na parte de ella se muestra en
la Tabla &$<$ _sta inclu,e considerar la intencionalidad- que ser un aspecto
mu, importante en este traba1o$
>:
Tabla &$;$ Ta0onoma de !urc*ase , Cinder$
Ti!" de
de$ect"
.ist"ria
?de$ect"@
Des&iacin
?$a))a@
Estad" #enta)
?e3ui&"cacin@
!erceptual Definicin
inicial de
requerimien
tos
@o se resuel+e
el problema de
la aplicacin
!roblema de
comunicacinI
anlisis
inadecuado del
problema
9euso Dise"o Comportamient
o inesperado e
indeseado del
elemento
reusado$
Conocimiento
inadecuado$
Jerarqua mal
entendida$ 3so
incorrecto de
protocolo
polimrfico$
4lgortmico Dise"o de
ob1etos ,
m2todos de
ni+el alto
Salida
incorrecta de
m2todo
(specificacin mal
entendida-
implementacin
incorrecta
Tabla &$&$ Ta0onoma de Firesmit*$
Gru!" De$ect"s
Defectos de
claseVob1eto
@o satisface requerimientosI
Modelo de estados incorrectoI
Fb1eto no almacenado$
Defectos de
mensa1es
!rotocolo de mensa1e equi+ocadoI
!armetro incompatibleI
8iolacin de estndares de dise"o o
codificacin$
Tabla &$<$ Ta0onoma de Landwe*r et al$
G1nesis
5ntencional malicioso Caballo de Tro,a
5nad+ertido (rror de +alidacin
(rrores lgicos$
Cu,nd"
Desarrollo dise"o
Mantenimiento
d/ 3na ta0onoma que considera ms el efecto- es decir la falla- es la de
%eier ?%eier- ;::'A- que se muestra en la Tabla &$B , que resulta
D'
interesante desde el punto de +ista de componentes- como se discutir ms
adelante$
e/ Los traba1os de ?F+erbec7- ;::BA , ?%inder- ;::DA presentan otras
ta0onomas- entre las cuales se pueden citar las de %erard .;::&/-
Jacobson et al .;::&/- Smit* , 9obson .;::&/ , Ja,es .;::B/$ !uede
notarse de las fec*as de las referencias que en los )ltimos a"os no *an
aparecido- siendo 2stos precisamente los que corresponden al desarrollo
de S%C$
Tabla &$B$ Gra+edad de fallas- seg)n %eier$
;$ Ligera# palabra mal escrita$
&$ Moderada# informacin redundante o enga"osa$
<$ Molesta# @ombres cortados- cuenta por c'$''
B$ 5nquietante# 4lgunas transacciones no procesadas$
>$ Seria# !erder una transaccin$
E$ Mu, seria# !rocesamiento incorrecto de una transaccin$
=$ Se+era# Fallas mu, serias repetidas$
:$ 5ntolerable# Corrupcin de base de datos$
;'$ Catastrfica# Cada del sistema$
;;$ 5nfecciosa# Cada que se propaga a otros sistemas$
5*:*4*B A8i"#as de adecuacin de c"n6unt"s de cas"s de !rueba
(n ;:=D- (laine Ce,u7er propuso oc*o a0iomas ?Ce,u7er- ;:=DA para asegurar la
adecuacin de con1untos de casos de prueba para un software dado$ (stos
a0iomas son mu, utiliados cuando se trata del tema , se les *a encontrado
muc*a aplicacin especialmente en software orientado a ob1etos ?!err, , Uaiser-
;::'A , posteriormente en software basado en componentes$ Los tres primeros
son intuiti+amente +lidos- pero los otros resultan poco e+identes a primera +ista$
(n ;:== la propia in+estigadora agreg otros tres a0iomas por considerar que los
primeros eran insuficientes ?Ce,u7er- ;:==A$ (stos )ltimos resultan tambi2n
intuiti+amente +lidos$ 4 continuacin se describen bre+emente$
;$ 4plicabilidad$ !ara cada programa e0iste un con1unto de pruebas adecuado$
&$ 4plicabilidad no e0*austi+a$ (0isten un programa ! , un con1unto de
pruebas T tales que ! es probado adecuadamente por T , T no es un
con1unto e0*austi+o$
<$ Monotonicidad$ Si T es un con1unto adecuado para ! , T es subcon1unto de
TN- entonces TN es adecuado para !$
B$ 5nadecuacin del con1unto +aco$ (l con1unto +aco no es un con1unto de
prueba adecuado para ning)n programa$
>$ 4ntie0tensionalidad$ (0isten programas ! , ` tales que !` .sus
especificaciones son equi+alentes/- el con1unto de prueba T es adecuado
para !- pero no es adecuado para `$
D;
D$ Cambio m)ltiple general$ (0isten programas ! , `- los cuales tienen la
misma forma- , un con1unto de prueba T que es adecuado para !- pero no
es adecuado para `$ .Son de la misma forma si se aplican las siguientes
reglas cualquier n)mero de +eces# a/ se reemplaa un operador relacional
r; por otro r&I b/ se reemplaa una constante c; por otra c&I c/ se
reemplaa un operador aritm2tico a; por otro a&/$
E$ 4ntidescomposicin$ (0iste un programa ! , un componente ` .parte de !/
tal que T es un con1unto de pruebas adecuado para !- TN es un con1unto de
+ectores de +alores que las +ariables pueden asumir al entrar a ` para
alguna t T , TN no es adecuado para `$ .3n componente probada en un
conte0to puede no estar adecuadamente probado- especialmente al
cambiar de conte0to/$
=$ 4nticomposicin$ (0isten programas ! , ` , un con1unto de pruebas T-
tales que T es adecuado para ! , el con1unto de +ectores de +alores que
las +ariables pueden tomar al entrar a ` para entradas en T es adecuado
para `- pero T no es adecuado para !I` .! compuesto con `/$ .La prueba
de componentes aislados no es suficiente para su composicin/$
:$ 9enombramiento$ Sea ! un renombramiento de Ì entonces T es adecuado
para ! si , slo si es adecuado para `$ .9enombramiento# !rogramas
id2nticos- e0cepto por el reemplao de cualquier identificador 0 en ` por
otro , en !- siempre que , no e0ista en `/$
;'$ Comple1idad$ !ara cada natural n e0iste un programa ! tal que ! es
probado adecuadamente por un con1unto de prueba de dimensin n- pero
no por ninguno de dimensin n6;$
;;$ Cobertura de proposiciones$ Si T es un con1unto de prueba adecuado para
!- entonces T causa que todas las proposiciones e1ecutables de ! sean
e1ecutadas$
2.1.) -iveles e pr"eba.
(0isten di+ersos alcances para las pruebas de software- que permiten agruparlas
por ni+el$ 4)n cuando no *a, un acuerdo uni+ersal- los ni+eles ms comunes son
tres#
i$ !ruebas de unidad- donde se prueban partes significati+as del producto
por separado$ La unidad puede ser una subrutina- un mdulo- una clase o
un componente$ Muc*as +eces la responsabilidad de tales pruebas
descansa en el propio codificador$
ii$ !ruebas de integracin- donde se +a probando la interaccin de unidades
,a probadas$ (s el ni+el ms descuidado$
iii$ !ruebas de sistema- donde se prueba el sistema completo$ (s el ms
com)n en las empresas , e0isten +ariaciones pre+ias a su liberacin ,
pruebas en el ambiente del usuario$
D&
Pruebas de integracin
4 primera +ista puede parecer que la prueba de integracin es innecesaria- si es
que las di+ersas unidades se probaron bien$ Sin embargo *a, +arias
consideraciones importantes#
H C"bertura !arcia)# cuando se considera que una unidad *a sido Kbien
probadaL- lo es de acuerdo a un criterio de cobertura , basado en seleccin
de casos de modo estadstico- por lo cual queda suficiente espacio para
defectos no identificados$
H De$ect" n" !r"!agad"# un defecto no siempre se propaga *asta producir
una falla- se tiene que un defecto que no produce falla en una unidad-
puede *acerlo al propagarse *acia otra.s/ unidades$
H Mecanis#"s de interaccin# al traba1ar 1untas +arias unidades- adems de
2stas inter+ienen otros elementos- que se dan por supuestos- pero que
inter+ienen en la comunicacin entre unidadesI estos elementos son los
mecanismos de cone0in- que el estudio de arquitectura de software *a
*ec*o ms +isibles$ Tales elementos pueden producir defectos que originen
fallas$
H E$ect"s de c"#!"sicin# cuando +arias unidades interact)an aparecen
di+ersos efectos que no corresponden a la simple suma de unidadesI son
efectos propios de la interaccin , no pueden ser probados en las unidades
separadas$ 4lgunos de tales efectos pro+ienen de acoplamientos no
pre+istos .por e1emplo +ariables comunes- estructuras de datos compartidas
o intento de una unidad por controlar a otra/$ Ftros efectos pueden
corresponder a caractersticas no funcionales- como rendimiento , uso de
recursos$
!or otra parte- las pruebas de sistema parecen cubrir los aspectos mencionados
arriba ,- nue+amente- podra suponerse que resulta innecesario realiar pruebas
de integracin$ 4l respecto tenemos tres problemas#
a/ L"ca)i'acin# si se prueba el sistema completo- sin pruebas intermedias de
integracin- ser difcil localiar un defecto$
b/ C"#!ensacin# un defecto en alguna unidad puede ser compensado
ocasionalmente por otro defecto o medida precautoria en otra unidad- , no
aparecer en los casos de prueba seleccionados .recu2rdese su naturalea
estadstica/$
c/ -a))as catastr$icas# algunos defectos en una unidad crtica para el
sistema pueden pro+ocar fallas catastrficas en el sistema- impidiendo su
operacin al grado de *acer imposible su prueba$
!or todo lo anterior- puede notarse la importancia de las pruebas de integracin
para el desarrollo de software$
2.1.4 ,r"ebas + calia el soft#are.
La calidad del software puede definirse de muc*as maneras$ 3na de las ms
limitadas- conocida como Kcalidad peque"aL define la calidad como la ausencia de
D<
defectos ?Uan- ;::>A$ !ara e+aluarla de esta forma se emplean procedimientos
estadsticos a partir de las tendencias de aparicin de fallas durante la prueba de
software$ (0isten estndares industriales que marcan aceptabilidad cuando se
estima el n)mero de defectos residuales en '$'& defectos por millar de lneas de
cdigo ?\amaura- ;::=A , a)n menos$
Ftros enfoque de calidad consideran di+ersos factores que la forman- entre ellos la
confiabilidad .!or e1emplo Me,er ?Me,er- ;::EA/$ (0iste una larga tradicin de
estudio de la confiabilidad que se asocia estadsticamente con el comportamiento
del software$
(0isten +arias formas de definir la confiabilidad- adaptadas de otras ramas de la
5ngeniera$ (n unos casos se considera tiempo de operacin , en otros la +ariedad
de usos propuestos$ De acuerdo con !oore- confiabilidad es la probabilidad de
que el software se comporte de acuerdo a sus especificaciones para un uso
seleccionado al aar ?!oore et al- ;::<A$
3na definicin ms reciente- de C*en- dice que Kla confiabilidad es la probabilidad
de operacin e0itosa de un programa dado- en un inter+alo de tiempo- en un
ambiente especificadoL ?C*en , Uao- ;::EA$
La confiabilidad se emplea de dos maneras$ La primera- durante el desarrollo de
un producto- llamada planeacin de confiabilidad- es una estimacin de 2sta a
partir de la confiabilidad conocida de partes que se estn integrando$ La segunda-
llamada tambi2n certificacin- es una medida de la confiabilidad de un producto
terminado- en forma e0perimental ?!oore et al- ;::<A$
!ara estimacin de la confiabilidad se utilian los casos de prueba que realmente
identifican fallas- llamndoseles casos efecti+os$
2.1.5 Calia e las pr"ebas.
Los casos de prueba , pieas de software au0iliar de las pruebas son tambi2n
productos de software- por lo que tambi2n estn su1etos a equi+ocaciones$ Seg)n
Jorgensen ?Jorgensen- ;::>A- la prueba se relaciona con la especificacin , la
implementacin de acuerdo al diagrama de la Figura &$&- que es una ampliacin
del que se mostr en la Figura &$;$ (n la figura se puede +er que la prueba puede
de1ar reas especificadas pero no probadas , tambi2n reas implementadas , no
probadas$ 4s pues- en un buen proceso de prueba los propios artefactos
empleados deben ser +erificados , +alidados$
3n aspecto relacionado es el llamado dise"o para la e0aminabilidad .design for
testability/- que es un enfoque de desarrollo que logra que el producto se
constru,a de modo que las pruebas descubran fcilmente los defectos$ 4l
respecto pueden consultarse los traba1os de %inder .?%inder- ;::B , ;::DA$
DB
E1;6/->-/5/-E.
I:;C6:6.85/-E.
P=@6F5
Figura &$&$ 9elacin entre (specificacin- 5mplementacin , !rueba$
5*5 Prueba de s"$t%are Orientad" a Ob6et"s*
(l desarrollo de software orientado a ob1etos *a ganado aceptacin mundial$ 3na
de las suposiciones iniciales que lo impulsaron fue la posibilidad de reutiliacin de
software- lo cual *a lle+ado al desarrollo de componentes$ Sin embargo- esta meta
obliga a asegurar la confiabilidad del software en un grado ma,or que en el
software con+encional$ !ara esto se deben efectuar pruebas que- a primera +ista-
pueden parecer ms simples- ,a que se est tratando con m2todos de reducidas
dimensiones , mdulos bien definidos , encapsulados$ Sin embargo- las mismas
caractersticas de software FF generan problemas especficos- no cubiertos por
las t2cnicas tradicionales de prueba$ (n esta seccin se describen estas
caractersticas , los enfoques que se *an dado a las pruebas- principalmente de
integracin$
(l software basado en componentes .S%C/ no presupone el uso de ob1etos pero-
en la prctica- los esfueros dominantes descansan sobre alg)n modelo de
ob1etos , los restantes suponen que- al menos- los componentes aparecen al
e0terior como grandes ob1etos- a)n cuando internamente puedan tener otra
estructura$ !or esta ran es con+eniente re+isar el estado actual de la prueba de
software orientado a ob1etos- porque ser+ir de base a la prueba de S%C$
2.2.1 &esarrollo orientao a objetos + pr"ebas.
(l desarrollo de software FF tra1o la esperana- para muc*os desarrolladores- de
que prcticamente no se necesitara probar los productos terminados- ,a que el
propio enfoque les permitira lograr software confiable$ 4s puede +erse en el
optimismo mostrado por autores como ?%ooc*- ;::;A , ?9umbaug*- ;::;A o en el
*ec*o de que la gran ma,ora de los te0tos rele+antes en desarrollo FF no
inclu,en un captulo sobre pruebas$
Jasta *ace unos pocos a"os solamente unos pocos autores *acan notar que este
tipo de software requiere pruebas como todo desarrollo *umano su1eto a errores$
Formalmente- !err, , Uaiser en ;::' ?!err, , Uaiser- ;::'A *icieron notar que en
realidad se requeran ms pruebas , no menos- como se pensaba$ Despu2s de
ellos- ?%erard- ;::<A- ?%inder- ;::BA- ?Jorgensen , (ric7son- ;::BA- ?Firesmit*-
D>
;::DA- %arbe,- ;::EA , ?Frso , Sil+a- ;::=A- entre otros- *an insistido en las
necesidades particulares de este tipo de software que obligan a ms pruebas$
4 principios de la d2cada de ;::'- el traba1o de ?!err, , Uaiser- ;::'A *aca notar
cmo el software orientado a ob1etos resaltaba la importancia de tres de los
a0iomas propuestos por Ce,u7er .tratados en la seccin anterior/# los de
antie0tensionalidad- antidescomposicin , anticomposicin$ (sto por la naturalea
de ese tipo de software- donde resulta ms frecuente reemplaar partes con la
misma especificacin .misma interfa/ , donde tiene ms sentido *ablar de partes
que se componen para formar un programa ma,or$
Jacia ;::B- a pesar de la con+iccin creciente de su necesidad- no pareca *aber
muc*o desarrollo de pruebas especficas para software FF- como lo muestra el
comentario de %inder al introducir un n)mero especial sobre el tema#
KHasta hace poco, se ha puesto relativamente poca atencin a considerar
pruebas de implementaciones orientadas a objetos.L ?%inder- ;::BA$
De ese tiempo a la fec*a la situacin *a cambiado- dandose un buen impulso al
tema- a)n cuando falta muc*o por *acer- como lo *ace notar el propio %inder#
KHoy, existen algunas herramientas, se han publicado muchas estrategias
de prueba y se tiene mucha experiencia colectiva, pero an uedan
algunos grandes retos.L ?%inder- ;::EA$
2.2.2 6"7 0ace iferente al soft#are OO.
(l desarrollo de software orientado a ob1etos tiene di+ersas caractersticas- como
la encapsulacin- la *erencia- el polimorfismo , la liga dinmica- que lo *acen
lograr software en tiempos ms reducidos- con me1or modularidad- con bastante
fle0ibilidad , posibilidades de reuso$ Sin embargo- esas mismas caractersticas
ofrecen un gran n)mero de oportunidades para defectos en el producto terminado$
Diferentes autores fi1an su atencin en distintos aspectos- por lo que se organian
como sigue#
Jerencia
5ntrnsecos !olimorfismo
Dependencia del estado
Costumbre Desarrollo incremental
5n+ocaciones implcitas
5mplementacin Cambio de tipo
!eculiaridades del lengua1e
Genericidad
9elacionados
(0cepciones
DD
!ara los fines de pruebas- muc*os de los problemas se agra+an por el
encapsulamiento- que bloquea la +isin del estado interno de los ob1etos , dificulta
grandemente las pruebas .+er por e1emplo ?%erard- ;::<A- ?%arbe,- ;::EA , ?Frso ,
Sil+a- ;::=A/$
Los principales problemas son#
a/ .erencia$ (sta es una propiedad mu, importante del software FF- que
genera una buena cantidad de problemas$ !or una parte- la *erencia
debilita el encapsulamiento , produce problemas seme1antes a los
causados por las +ariables globalesI por otra parte- muc*as +eces se
abusa de la *erencia como un mecanismo de reutiliacin de cdigo
fuera de conte0to$ (n general se tienen muc*as oportunidades de
cometer equi+ocaciones al refinar- redefinir o eliminar propiedades de
clase antecesora$ Los problemas se agra+an cuando se forma una
1erarqua .o lati si *a, *erencia m)ltiple/ mu, alta , anc*a$ Los
problemas ms notorios son de incompatibilidad semntica$ Se agra+a
en cone0in con problemas de polimorfismo , de implementacin$
!ueden consultarse ?F+erbec7- ;::BA- ?Junt- ;::>A- ?%inder- ;::DA-
?%arbe,- ;::EA , ?Frso , Sil+a- ;::=A$ (n general se recomienda cuidar la
definicin de subclases , tratar de que estas correspondan a subtipos
.!rincipio de sustitucin de Lis7o+ ?Lis7o+- ;:==A/$
b/ P")i#"r$is#" , liga dinmica$ (sta caracterstica permite la construccin
de sistemas mu, fle0ibles- que pueden tratar con ob1etos instanciados
*asta el tiempo de e1ecucin- por lo cual no se pueden +erificar antes$
(sto aumenta e0ponencialmente el n)mero de caminos posibles que
deben +erificarse , puede generar incompatibilidades semnticas a su
mane1o$ (n el caso ms comple1o se tiene polimorfismo en el ob1eto que
llama- en el llamado , en los parmetros que se en+an$ Se supone
asociado a abuso de subclases que no corresponden a subtipos$ 8er
?Me,er- ;::EA- ?%arbe, et al- ;::BA- ?Frso , Sil+a- ;::=A , especialmente
?%inder- ;::DA que inclu,e +arias referencias$
c/ C"#!"rta#ient" din,#ic"$ 4 diferencia del software tradicional- donde
la estructura de datos global mantiene un estado tambi2n global , los
procedimientos , funciones no guardan estado entre in+ocaciones
sucesi+as- el software FF presenta un comportamiento que depende del
estado interno de cada uno de los ob1etos- que lle+an una *istoria del
proceso , la e1ecucin de un m2todo depende del estado particular del
ob1eto que lo contiene$ De este modo- la respuesta a un mensa1e no
depende )nicamente de su contenido- sino del estado actual del ob1eto
que lo recibe$ (ste problema se *ace ms notable cuando se distribu,e
el control sobre muc*os componentes , cuando se emplean enfoques
clienteVser+idor$ (ste *ec*o es destacado- entre otros- en Fran7l ,
Jamlet ?Fran7l , Jamlet- ;::EA , en Smit* , 9obson ?Smit*X- ;::'A/$
Tambi2n se detalla en ?%arbe, et al- ;::BA- ?%inder- ;::DA , en ?Frso ,
Sil+a- ;::=A$
DE
d/ Desarr"))" incre#enta)$ (sta prctica mu, asociada con el software FF
origina grupos de componentes con alta co*esin entre ellas ,- por otra
parte- genera bibliotecas con irregularidades- como repeticin de
funciones , funciones di+ididas entre +arias clases$ (ste problema se
trata en ?%inder- ;::>A , en ?Junt- ;::>A$
e/ In&"caci"nes i#!)0citas$ (stas se refieren a in+ocaciones relacionadas
con creacin , destruccin de ob1etos$ !or su asociacin con la *erencia-
puede ocurrir que se destru,a un ob1eto suponi2ndolo de una clase-
cuando en realidad era de una subclase de aquella o que se tenga un
ob1eto construido a medias$ (stos problemas se encuentran citados en
?%arbe, et al- ;::BA , ?Frso , Sil+a- ;::=A , se detallan en el traba1o de
Junt ?Junt- ;::>A$
f/ C"n&ersi"nes$ 4l forar con+ersiones .casting/ se modifican las caractersticas
de ob1etos o sus propiedades en forma dinmica- por lo cual
resultan indetectables al tiempo de compilacin$ (ste problema se agra+a
cuando se emplea CXX$ !uede +erse en ?%arbe, et al- ;::BA- ?%inder-
;::DA , ?Frso , Sil+a- ;::=A$
g/ Pecu)iaridades de) )engua6e$ Cada lengua1e adapta los principios de
FF en diferente forma- con +enta1as , des+enta1as sobre otros$ 3no de
los lengua1es ms empleados en desarrollo FF es CXX- que fa+orece un
gran n)mero de problemas- como lo *acen notar di+ersos autores- como
Junt ?Junt- ;::>A , %inder ?%inder- ;::DA$ 8arios de tales problemas se
asocian a caractersticas ,a mencionadas- especialmente las
in+ocaciones implcitas- las con+ersiones , la *erencia$ (l uso de
elementos afrienda permite romper el encapsulamiento- permitiendo la
ocurrencia de defectos en clases ,a probadas .problema similar al uso de
+ariables p)blicas como default en Ja+a/$ Ftro problema com)n es el
mane1o deficiente de la memoria que origina sobreflu1o$ 4lgunas
implementaciones de CXX parecen menos propensas a errores- en
e0periencia del autor$
*/ Genericidad$ (ste concepto se refiere a la creacin de tipos
parametriados como los Templates de CXX/- que generan elementos no
e0aminables *asta que son instanciados$ (ste tipo de elementos tienen
gran +ariedad de opciones , algunas de ellas pueden ser correctas
mientras otras generan fallas$ (ste problema se trata en ?Frso , Sil+a-
;::=A , ?%inder- ;::DA$
i/ E8ce!ci"nes$ Cualquier anomala que se presenta al tiempo de
e1ecucin- sea del sistema o de la aplicacin- puede originar que el
software siga un camino implcito- generando mensa1es- por lo cual debe
considerarse su ocurrencia$ (ste no es un problema pri+ati+o del
software FF- pero tiene un fuerte impacto sobre 2l$ 8er ?Frso , Sil+a-
;::=A$ (n forma general- como un enfoque complementario al de ob1etos-
se *a comenado a desarrollar la llamada !rogramacin Frientada a
4spectos- que inclu,e consideraciones especiales para el problema de
las e0cepciones ?Uicales et al- ;::EA$
D=
4 pesar de la lista anterior- que proporciona una buena coleccin de *iptesis de
defectos- no e0iste una ta0onoma completa de defectos de software FF- por lo
cual no se tiene un con1unto suficiente de t2cnicas de prueba$
2.2.( ,r"ebas e integracin en /OO
La prueba de software orientado a ob1etos inclu,e- a grandes rasgos- los mismos
ni+eles del software en general$ Sin embargo su definicin cambia por la
naturalea especfica de este tipo de software$
Pruebas de unidad
Lo que se entiende por KunidadL para las pruebas de ese ni+el- son moti+o de
dudas en autores de mediados de la d2cada de ;::'- pero actualmente parece
*aber acuerdo que la unidad mnima a probar es la clase- ,a que los m2todos por
s solos no son independientes- en ran al estado de la clase$ !ara su prueba se
e1ecutan casos de prueba que cubran el e1ercicio de cada m2todo al menos una
+e$ Si se emplean pruebas de estructura- se apro+ec*a el *ec*o- obser+ado
e0perimentalmente- de que la comple1idad ciclomtica tpica de los m2todos se
sit)a alrededor de cuatro- siendo as relati+amente fcil su +erificacin$ Los
problemas ms comple1os- a este ni+el- pro+ienen de m2todos que deben ser
in+ocados en alg)n orden , no en otro$
!ara pruebas de unidad se apro+ec*an caractersticas del software FF- en
especial la *erencia$ 4s- al probar clases deri+adas de una ,a probada- los
m2todos *eredados sin cambio , que slo interact)an con otros ,a probados- no
se pruebanI aquellos que cambiaron se prueban reutiliando casos de prueba ,
restan los m2todos nue+os- para los cuales se deben desarrollar casos de prueba
nue+os$ (sto )ltimo es necesario tambi2n para interacciones que in+olucran
m2todos nue+os o cambiados$
!ara pruebas de este ni+el e0isten *erramientas en el mercado que automatian
su e1ecucin- especialmente ligadas con el lengua1e CXX , )ltimamente con Ja+a$
3n buen te0to dedicado a pruebas de unidad de software FF es el libro de Siegel
?Siegel- ;::DA$
Pruebas de siste#a
(n cuanto a las pruebas de sistema- por su naturalea- son similares en cualquier
tipo de software- pues se prueban elementos +isibles al usuario final- ni+el donde
no importa tanto la forma de implementacin$
Pruebas de integracin
La prueba de integracin es aquella que se realia para identificar cualquier falla
cuando dos o ms elementos desarrollados independientemente se combinan
para e1ecutar sus funcionalidades ?%as*ir , Goel- &'''A$ (ntre las fallas tpicas se
tienen las debidas a defectos internos , e0ternos en las interfaces- fallas de
sincroniacin , de rendimiento$
D:
(n el ni+el de integracin se inclu,e lo que algunos autores llaman prueba de
clusters , prueba de interaccin entre clases$ (n general comienan por llamadas
desde fuera del grupo de clases ba1o prueba , se sigue la secuencia *asta
terminar en un punto en reposo- en una salida al e0terior de ese grupo$ (s un ni+el
menos desarrollado que el de pruebas de unidad- pero es el ms importante para
la prueba de componentes$ (n este ni+el el 2nfasis esta en la interaccin de
m2todos$
3na estrategia general- adaptada de la prueba de software tradicionales la de
caminos MM de JorgensenI dos de las pocas estrategias especficas para ob1etos
reportadas son la de F+erbec7 , la de Uung , sus colaboradores$ 9ecientemente
se publicaron dos libros dedicados a prueba de software- uno de %inder- mu,
e0tenso- , otro de %as*ir , Goel- ms reducido , concreto$ Las diferentes
propuestas se describen a continuacin$
M1t"d" de ca#in"s MM*
Jorgensen propone una adaptacin de pruebas de integracin basadas en
caminos de mensa1es que +an acti+ando m2todos .MM6!at*s/- especialmente
aquellos que se inician por un e+ento de entrada$ 5dentifica tambi2n las llamadas
funciones atmicas del sistema .4SF por sus siglas en 5ngl2s/ que abarcan +arios
MM6!at*s iniciados por un e+ento de entrada , terminados por un e+ento de
salida- de modo que corresponde a una unidad +isible al e0terior del sistema
?Jorgensen , (ric7son- ;::BA , ?Jorgensen- ;::>A$
M1t"d" de O&erbec/*
F+erbec7 ?F+erbec7- ;::BA- propone un enfoque donde se prueba las clases por
pares- donde una *ace el papel de cliente , otra de ser+idor$ !ropone dos
con1untos de pruebas# el primero de clase- que es aprobado si la clase cumple con
tres pruebas#
;/ todas las entradas , salidas de mensa1es son correctasI
&/ se usa correctamente cualquier clase ser+idora ,
</ todas las secuencias de operaciones son correctas$
(l segundo grupo se aplica por pares$ Si [ es la clase cliente , \ la ser+idora- se
satisface el con1unto si
;/ [ pasa todas sus pruebas de clase .primer grupo/I
&/ [ siempre satisface las precondiciones de \ ,
</ [ usa correctamente las salidas de \$
Si el con1unto de clases no contiene ciclos- se puede probar sin cabos .stubs/-
pero si e0isten ciclos se debern agregar stubs para romper los ciclos$ Con este
enfoque se prueban las di+ersas combinaciones de *erencia de las clases cliente
, ser+idora- reutiliando los casos de prueba cuando sea aplicable$
E'
M1t"d" de Cung ( sus c")ab"rad"res*
Uung , sus colaboradores ?Uung et al- ;::>A *an desarrollado una estrategia que
emplea ingeniera en re+ersa sobre el cdigo para crear un diagrama de
relaciones entre ob1etos .F9D/- a partir del cual se propone un orden de pruebas
que minimia el uso de cabos$ !ara *acerlo con+ierten el F9D en un digrafo
acclico- que puede contener +arios clusters de ob1etos- , luego los ordenan
topolgicamente$ Su m2todo in+olucra las etapas de prueba de unidad , de
integracin , puede usarse tambi2n para pruebas de regresin$ (l proceso se
encuentra automatiado- seg)n lo reportan$
M1t"d" !r"!uest" !"r +as2ir ( G"e)
?%as*ir , Goel- &'''A consideran dos tipos de prueba# una estructural , otra
funcional- que debe estar guiada por los casos de uso , una lista de clases listas
.es decir que pasaron sus pruebas de unidad/$
(n la primera- los casos de prueba sern generados al aplicarse un enfoque
estructural a la interaccin de pares de clases- suponiendo de alguna manera una
relacin de contencin$
(n la segunda- los casos de uso guiarn al probador o a la *erramienta
automtica sobre el orden de seleccin de clases a probar- su1eto a la
disponibilidad de clases listas$ 3na +e seleccionado el orden- se eligen casos de
prueba$
4 continuacin se describen bre+emente su generacin de casos de prueba a
partir de enfoque estructural , el funcional a partir de los casos de uso$
!rueba estructural$
Se supondrn dos clases# 4 , %- donde 4 contiene a %$
Se utiliarn las llamadas Matrices de uso de datos .M3D o D!" por sus siglas
en ingl2s/- las cuales se constru,en como sigue#
i$ las columnas de la matri se etiquetan con los nombres de los m2todos de la
claseI
ii$ las filas de la matri se etiquetan con los nombres de los atributos de claseI
iii$ los elementos de la matri se llenan como sigue# el ndice l representa el ni+el
de uso- reporte o transformacin- donde ; es directo , & indirecto$
tl si el m2todo 1 transforma al atributo i
rl si el m2todo 1 reporta el estado del atributo i
M.i-1/ Q
ol si el m2todo 1 usa el atributo i
+aco si no interact)an
E;
La generacin de casos de prueba estructurales siguen los pasos siguientes-
alrededor de tres e1es ortogonales#
i$ se genera la M3D para la clase contenedora .4/- acomodndola en el plano
[\
ii$ se genera la M3D para la clase contenida .%/- acomodndola en el plano d\
iii$ se genera una matri de colaboracin en el plano [d- e0tendiendo las
columnas de m2todos de 4 , de % , marcando los elementos
correspondientes a m2todos de 4 que interact)an con m2todos de %$
i+$ !ara cada fila de la clase 4 .es decir cada atributo/- se listan secuencias de
m2todos que afectan al estado del atributo$
+$ !ara cada secuencia de m2todos del paso anterior- se agrega informacin de
los m2todos de % que son llamados por los de 4$
+i$ Se de1an las secuencias de m2todos de % que son in+ocados , se eliminan
llamadas a m2todos de % que no afecten al atributo ba1o anlisis$
+ii$ Se reemplaan los m2todos de % por el m2todo de 4 que los in+ocaI las
secuencias de m2todos de 4 sern las que corresponden a casos de
prueba$
+iii$ Se generan los casos de prueba a partir de las secuencias anteriores$
,
,
,
,
,
,
,
,
,
,
A.:1 A.:2 A.:3
A.71
A.72
A.73
B.:1
B.:2
B.:3
B.71
B.72
B.73
Figura &$< Matrices de uso , de colaboracin
(n resumen- los casos de prueba refle1an in+ocaciones de m2todos que afecten el
estado de la clase contenedora$ 9ecu2rdese que- al ser prueba estructural-
solamente es aplicable si se dispone de acceso a la implementacin de las clases$
!rueba funcional
!ara la prueba funcional se parte de los casos de uso , se generar un rbol de
dependencia entre ellos como sigue#
E&
i$ cada nodo es un caso de uso
ii$ cada arco es una relacin de dependencia- que indica que el caso de uso
dependiente emplea ob1etos del caso de uso del que depende$
iii$ las *o1as representan casos de uso que no dependen de ob1etos de otro caso
de uso$
Con el rbol listo- se procede como sigue para generar una lista de casos de uso
para guiar las pruebas#
i$ se probarn primero los casos de uso de las *o1as- para lo cual se ordenan
por comple1idad .depende del probadorI puede ser n)mero de clases
in+olucradas- comple1idad interna o grado de interaccin entre clases/ , se
agregan a la cola$
ii$ procediendo de las *o1as a la ra- se consideran nodos que slo dependen
de los casos de uso ,a registrados en cola- se ordenan , se agregan a la
cola- repiti2ndose *asta terminar con los casos de uso$
4 partir de la cola se irn seleccionando casos de usoI se realian pruebas
estructurales entre ob1etos in+olucrados- luego pruebas funcionales , por )ltimo
pruebas no funcionales .como rendimiento/$
Pr"!uesta de +inder
!ara %inder ?%inder- ;:::A- las pruebas de integracin en sistemas orientados a
ob1etos tienen di+ersos ni+eles- que se sit)an con dos elementos definitorios# el
foco , el alcance$ (l foco nos dice cules son los componentes ba1o estudio , el
alcance cul es el sistema constituido por los componentes$ !ara este in+estigador
el t2rmino KcomponenteL cubre elementos tales como m2todos- clases- clusters de
clases , subsistemas$ (l t2rmino sistema puede cubrir clases- clusters-
subsistemas , sistemas completos$ Con tales elementos se pueden identificar
+arios ni+eles de integracin# m2todos en una clase- clases en un cluster- clusters
en un subsistema , subsistemas en un sistema$
(n cada ni+el- considera deben realiarse al menos tres tipos de prueba#
a/ indi+idual a cada componenteI
b/ del sistema resultante de federar los componentesI
c/ de interoperacin$
Considera tambi2n que las pruebas de integracin estn mu, ligadas a la
arquitectura del sistema , al proceso de desarrollo$ 4l respecto- en el caso FF el
proceso de desarrollo es de integracin continua$
Las pruebas de integracin deben tomar en cuenta las dependencias que se
forman entre componentes- algunas e0plcitas como las deri+adas del proceso de
liga- de la *erencia- in+ocacin de 4!5s- parmetros- +ariables globales-
intercambio de mensa1es o las llamadas remotas a procesosI otras implcitas como
la comunicacin +a un almacenamiento persistente- por restricciones de
E<
secuencias de acti+acin o por restricciones de tiempo$ (stas )ltimas no las
considera en el dise"o de pruebas$
Finalmente- organia las pruebas de integracin que recomienda en forma de
patrones- que inclu,en los tradicionales , otros especficos para distintos tipos de
sistemas$ Los patrones que considera son#
big bang
descendente .top6down/
ascendente .bottom6up/
colaboracin
columna +ertebral .bac7bone/
capas
clienteVser+idor
ser+icios distribuidos
alta frecuencia
De ellos- los ms rele+antes para este traba1o son los de clienteVser+idor , de
ser+icios distribuidos- que se resumen a continuacin$ Debe notarse que no da
detalles mu, particulares- sino elementos generales para realiar las pruebas$
!ara los detalles debe consultarse su obra$
C)ienteDser&id"r
Se aplica a sistemas d2bilmente acoplados con un solo ser+idor$ Deben
identificarse claramente los clientes , el ser+idor$
!ruebas#
Se prueba el ser+idor con stubs de cliente
Se prueba cada cliente diferente con stub de ser+idor
!ares de clientes con ser+idor , stubs de otros clientes
Todos los clientes , ser+idor
(l m2todo se puede ampliar a sistemas de tres o ms ni+eles- inclu,endo el F9%
o su software intermedio equi+alente- como sigue#
!ruebas#
Cliente , F9%
ser+idor , F9%
clientes- F9% , pro0, de ser+idor
ser+idor- F9% , pro0,s de clientes
clientes- F9% , ser+idor
(n cualquier caso- los criterios a satisfacer son#
a/ cada componente *a sido probado
b/ cada interfa se *a e1ercitado al menos una +e
c/ se *an realiado pruebas en ambiente isomorfo al definiti+o
EB
Ser&ici"s distribuid"s
(ste patrn se recomienda cuando el sistema inclu,e un con1unto de componentes
que corren concurrentemente- sin que *a,a un centro de control$ (ste tipo de
sistemas se desarrollan con muc*a confiana en el software intermedio- ,a que el
enfoque FF no tiene soporte especfico para ellos$
Los sistemas de este tipo de resultan difciles de probar porque e0isten muc*as
secuencias de control$ La prueba puede guiarse por el riesgo que representara la
falla de cada uno- por las dependencias identificadas o por prioridades- donde los
ser+icios de seguridad son prioritarios$
!ara las pruebas se recomienda separar aquellas que son independientes del
nodo , las que dependen del mismoI deben considerarse todos los nodos remotos
tpicos que puedan corresponder con el sistema ba1o prueba$
Las pruebas independientes se realian primero , despu2s se +an *aciendo las
que dependen de *ost$ Luego se +a agregando un *ost a la +e- *asta tenerlos a
todos$
Los criterios a satisfacer son similares a los de clienteVser+idor$ Las pruebas se
suspenden cuando se *an probado todas las interfaces , todos los nodos remotos
tpicos$
2.2.) /it"acin act"al.
9esumiendo la situacin actual de la prueba de software orientado a ob1etos- se
tiene que#
H 4 ni+el de unidad se *an desarrollado un gran n)mero de t2cnicas de
prueba , se est traba1ando acti+amente en di+ersos grupos$ Sin embargo-
*ace falta traba1o en el rea de comparacin de m2todos , maneras de
complementarlos$
H 4 ni+el de sistema no *a, grandes no+edades , se siguen m2todos ms o
menos tradicionales$
H 4 ni+el de integracin *ace falta muc*o- especialmente para el caso del
polimorfismo$ Los m2todos reportados se concentran principalmente en la
prueba de clases implementadas- pero *a, poco de pruebas de otros
productos de software que pudieran identificar problemas antes de
codificar$
La situacin aqu discutida es ma,ormente acad2mica$ Ja, pocos informes
+alidados acerca de la prctica- pero en general se considera que 2sta +a bastante
atrs$ 3no de los pocos resultados concretos de anlisis de la situacin en la
industria es el presentado por ?%inder- ;::EA- donde se resume as la situacin#
E>
a/ Dos tercios de las empresas analiadas realian pruebas en desorden- con
poca planificacin$ Se prueban las funcionalidades ms importantes .ni+el
de sistema/- de1ando pruebas de unidad ba1o responsabilidad de los propios
desarrolladores$
b/ 3na cuarta parte de las empresas desarrollan pruebas por casos de uso$
3san algunas *erramientas para captura , repeticin.)tiles para pruebas de
regresin/$ La prueba de clases- clusters , componentes se de1a a
discrecin del desarrollador$
c/ (l resto- un ;'b- realian pruebas sistemticas por alcance creciente- de
clase- cluster- componente- subsistema , sistema- ba1o un plan detallado
por metas$
Seg)n ?%inder- ;::EA- en lo el futuro se deber desarrollar ms la programacin
por contrato .de Me,er/ , las autopruebas$ (ste )ltimo elemento presenta +arios
problemas# *ace ms grandes las clases , los componentes , abre una nue+a
puerta a fallas al permitir reutiliar el cdigo de las pruebas para otros propsitos-
debido al problema de abuso de reutiliacin que se mencion antes$
5*: Pruebas de s"$t%are basad" en c"#!"nentes
4l igual que en el caso del software orientado a ob1etos- los entusiastas del S%C
no se preocupan demasiado acerca de la necesidad de pruebas$ Los reportes
comerciales indican que )nicamente se da importancia a pruebas de conformidad
con el software intermedio elegido , recomiendan pruebas de unidad- sin alguna
caracterstica especial$ La prueba de integracin es ignorada a pesar de no e0istir
modelos adecuados acerca del comportamiento de componentes agregados en
sistemas$
Tambi2n debe notarse que no e0isten estndares de prueba de software basado
en componentes- como consecuencia de no *aber estndares de 2ste tipo de
software$
2.(.1 -ecesiaes e pr"eba e componentes.
(n el captulo anterior se describi el software basado en componentes .S%C/$ De
la descripcin puede notarse que e0isten diferencias respecto a otros tipos de
software- a pesar de las similitudes ine+itables$ 4lgunas diferencias generan
necesidades de prueba diferentes a otros tipos de software$ 4s pues- es
necesario determinar cules son las necesidades especiales de prueba del S%C$
5*:*4*4 Di$erencias i#!"rtantes*
(l S%C tiene una serie de caractersticas que lo *acen requerir pruebas en forma
diferente a otros tipos de software$ La Tabla &$> presenta algunas de tales
caractersticas mostrando el problema que generan$
ED
Tabla &$>$ Caractersticas del S%C que influ,en en pruebas$
Caracter0stica Pr"b)e#a C"#entari"
(ncapsulamien
to
Funciones ocultas (l encapsulado , falta de acceso
al cdigo fuente impiden aplicar
m2todos de prueba estructural ,
facilitan la e0istencia de
funcionalidades ocultas$
(ncapsulamien
to
!2rdida de
responsabilidad
Con acceso al cdigo fuente- la
labor de prueba +a mu, ligada
con la depuracin- que le da un
sentido prctico$ Cuando no se
tiene- no e0iste esta liga- lo cual
*ace pensar al desarrollador que
no es su responsabilidad$
9eutiliacin Degradacin de
recursos por
funciones
innecesarias
(l reuso obliga a aceptar el
componente con toda su
funcionalidad- a)n cuando no se
requiera$ !ara pocos elementos-
no es gra+e- pero cuando el
n)mero de componentes crece- la
sobrecarga de elementos , el
traslape de funciones puede
complicar el software- degradar
su rendimiento , fa+orecer usos
impre+istos de funciones
adicionales$
9eutiliacin Diferente perfil de
uso
(l uso de una de componentes
en diferentes aplicaciones genera
perfiles de uso mu, diferentes- lo
cual afecta la preparacin de
casos de uso , su posterior
seleccin$ Si un componente se
prueba para una aplicacin- se
debe centrar en los casos ms
probables- que constituirn su
perfil de uso Sin embargo- al
emplear el mismo componente en
otra aplicacin- es mu, posible
que las pruebas realiadas no
cubran gran parte de sus casos$
5nteroperacin !roblemas de
compatibilidad de
mecanismos
La 5nteroperabilidad de elementos
*eterog2neos genera problemas
de KpegadoL entre los
componentes$ !ueden surgir
conflictos entre mecanismos
diferentes pero con el mismo
EE
Caracter0stica Pr"b)e#a C"#entari"
propsito- como es el paso de
e+entos- el mane1o de estructuras
de datos , otros$
Distribucin (l S%C es- en muc*os casos-
distribuido$ (sto genera un gran
n)mero de defectos- por
incompatibilidad de software de
apo,o .redes/- sistemas
operati+os , *ardware$
Concurrencia La concurrencia acarrea un gran
n)mero de dificultades- que
inclu,en# sincroniacin- mane1o
de un n)mero grande de
procesos concurrentes- mane1o
de recuperaciones e integridad de
transacciones$
Despliegue
independiente
!ruebas
pospuestas *asta
operacin
(l despliegue independiente , a
+eces pospuesto al lmite-
impiden pruebas completas antes
de la operacin normal$
4daptacin en
despliegue
(lementos
adicionales a
probar- a +eces
ocultos
La posibilidad de adaptar
propiedades de los componentes
al tiempo de despliegue introduce
elementos adicionales a probar-
que pueden quedar ocultos$
Contenedor 8ariacin de
conte0to
!ueden e0istir diferencias de
ambiente operati+o entre el
sistema donde se prueba , aquel
donde se e1ecuta en realidad$
5nterfaces que
se descubren
en e1ecucin
4coplamientos
inesperados ,
acceso no
deseado
(l mecanismo que permite la
identificacin de interfaces al
tiempo de e1ecucin permite
interacciones no documentadas$
Descripcin
puramente
sintctica de
interfaces
Confusin de
parmetros
Los modelos comerciales dan
2nfasis casi )nico a las interfaces
ofrecidas , a)n 2stas slo a ni+el
sintctico$ (sto permite confundir
una interfa al tiempo de
e1ecucin- ,a sea por defecto de
programacin o por defecto de
documentacin$
E=
5*:*4*5 Necesidades en di$erentes eta!as de) cic)" de &ida
(l software basado en componentes .S%C/ requiere pruebas en diferentes etapas#
en el desarrollo del componente- en su seleccin , e+aluacin , al ser integrado
en alguna aplicacin$ 4lgunas pruebas son similares a las del software tradicional
, al orientado a ob1etos- especialmente con los enfoques descritos en ?%inder-
;:::A- pero otras son particulares del S%C$ 4lgunos aspectos de la prueba a)n
estn por estudiarse$
Eta!a de desarr"))" de) c"#!"nente*
\a que un componente tiene cierta independencia- llegando incluso a ser una
aplicacin completa- las pruebas en su desarrollo son similares a las del software
tradicional .inclu,endo ba1o esta denominacin al software orientado a ob1etos/$
4lgunas consideraciones son las siguientes#
H Necesidades es!ecia)es de !rueba en SOO$ (n muc*os casos los
componentes siguen un modelo de ob1etos , de a* se deri+an dificultades
para su prueba- ,a que se sabe que el software FF e0ige ms pruebas que
el tradicional , con pruebas un tanto diferentes a las usuales ?%inder- ;::DA$
(l problema es ms gra+e en el caso del polimorfismo$
H Pruebas de integracin dentr" de un c"#!"nente$ Si el componente es
comple1o- en su desarrollo ser necesario aplicar pruebas de integracin-
que corresponden al rea menos desarrollada en el campo de pruebas de
software$ (sto es especialmente importante si siguen una orientacin a
ob1etos$
H -a)ta de !ruebas en s"$t%are )egad"$ Si el componente corresponde a
software legado- es mu, probable que nunca *a,a sido probado
formalmente , al con+ertirlo en componente pueden aparecer problemas
ocultos- ,a que cambiar su manera de interactuar con el e0terior$
H C"#!"nente e8tra0d" de a!)icacin$ Si el componente se e0trae de
aplicaciones pree0istentes- e0isten +arias consideraciones# cuando se prob
se supuso un cierto perfil de operacin que se tradu1o en un cierto grado de
cobertura$ 4l aislarlo- ese perfil ,a no ser +lido$ Ftra consideracin es que
puede *aber e0istido un defecto que era neutraliado por el resto de la
aplicacin- impidiendo su propagacin *asta el e0teriorI as- el defecto estar
oculto$ 4l quitar la aplicacin- el defecto se mostrar , podr propagarse
*acia otros componentes$
Eta!a de se)eccin ( e&a)uacin de c"#!"nentes*
(n esta etapa- aunque pareca que el mismo componente requiere las mismas
pruebas- debe notarse que las suposiciones que *a,a tenido su desarrollador
original pueden ser mu, diferentes a las de quien las desea emplear ?Ce,u7er-
;::=A- por lo que su perfil de operacin ser diferente , con ello los casos de
prueba que deben aplicarse$ 4l e+aluar un componente se deben considerar dos
partes ?8oas- ;::= bA#
i$ que satisfaga las funciones requeridasI
E:
ii$ que tenga buena calidad .traducida en que no ocasione fallas/$
La primera parte se puede complicar si se pretende una seleccin automtica de
componentes , queda asociada con el desarrollo de m2todos de especificacin
formal de componentes$
Las pruebas en esta etapa sern similares a la anterior- si se dispone del cdigo
fuente- al menos para consulta$ (n cambio- si se tiene un encapsulamiento
estricto- surgirn problemas gra+es- ,a que se tendra que probar a ciegas$ 4)n
los m2todos de ca1a negra emplean conocimiento de la implementacin para dar
buenos resultados- como lo *ace notar ?%eier- ;::>A$
Si no se tiene acceso al cdigo fuente o apenas se permite consultarlo- e0iste la
posibilidad de que se identifiquen defectos- pero que no se puedan corregirlo que
puede causar cierta frustracin en los desarrolladores- como lo *ace notar
?Ce,u7er- ;::=A$
Con encapsulamiento estricto *abra que considerar la posibilidad de que e0istan
funcionalidades indeseadas , no documentadas- incluso maliciosas$ 4dems-
pueden e0istir salidas al sistema operati+o por mal mane1o de e0cepciones ?8oas
et al- ;::E bA$
Eta!a de integracin de c"#!"nentes*
(sta es la etapa en la que surgen ms aspectos propios del S%C$ 5nicialmente se
tendrn que considerar aspectos relacionados con la arquitectura de la aplicacin
, luego una serie de elementos particulares relacionados con el software
intermediario- los modelos de los componentes , otros$
(n relacin a la arquitectura debern considerarse las recomendaciones de Garlan
, sus colaboradores ?Garlan et al- ;::>A- que se refieren principalmente a las
suposiciones acerca de componentes , conectores$
(n cuanto al modelo de componentes#
H Jerencia$ (n este punto los di+ersos modelos de componente se
comportan de diferente modo$ 4lgunos emplean la *erencia con todas sus
consecuencias , otros se limitan a usar agregacin , delegacin$ (n el
primer caso- la *erencia afectar la prueba de componentes en forma
similar a como lo *ace con los ob1etos$
H !olimorfismo , liga dinmica$ Jasta donde se *a desarrollado el concepto
de componente- el polimorfismo ser algo mu, com)n , la liga dinmica
tambi2n aparece como necesaria .a)n como indispensable- como por
e1emplo en .+er prefacio a ?%o0- ;::=A/- sobre todo cuando se *abla de
componentes distribuidos$ (l efecto de estas caractersticas ser similar al
caso de ob1etos- pero agra+ado por el *ec*o de que los componentes
='
pueden tener una ma,or granularidad , en muc*os casos probablemente
residan en equipos diferentes$
H Comportamiento dinmico$ (l comportamiento dinmico del componente
ser mu, importante$ Los modelos actuales consideran la posibilidad de
componentes sin estado o con estado permanente , a)n con un estado que
se almacenara en disco$ La e0istencia de estado introduce problemas de
prueba por la necesidad de considerar la *istoria- en forma seme1ante al
software FF- pero con la comple1idad de los componentes$ (n cualquier
caso- su ocultamiento es ms fuerte por la encapsulacin , por la ausencia
de cdigo fuente$ ùi si el componente es ms autnomo e0ista menor
problema de la *istoria durante su e1ecucin$ (0isten riesgos de
funcionalidades ocultas$ 4qu deben cuidarse los problemas de
identificacin errnea de interfa , de interfaces mal documentadas$
H (0cepciones$ (ste aspecto sigue siendo de gran importancia- aumentado
por el desconocimiento de la implementacin interna del componente$
!ueden surgir salidas impre+istas que +a,an directamente al sistema
operati+o o impongan cargas impre+istas sobre la aplicacin$ 4)n cuando
se cubra el componente con un adaptador- el riesgo permanece$
(n cuanto a la cone0in entre componentes- debe considerarse#
H Los componentes pueden comunicarse inadecuadamente los parmetros o
estructuras de datos- generando situaciones no pre+istas por el
desarrollador del componente$
H 3na tendencia en el software actual es *acia los sistemas distribuidos$
5ntegrar componentes en estos sistemas inclu,e otros problemas- como son
el paso de apuntadores , ob1etos- la concurrencia ,- en general- la referencia
a elementos presentes en un espacio diferente de direcciones$
5*:*4*: Pruebas !"r ni&e)
Las pruebas en S%C tienden a meclar los ni+eles tpicos de unidad- integracin ,
sistema- un poco como ocurre en el software FF- como lo *ace notar %inder
?%inder- ;:::A$ (n el caso de componentes- su propia naturalea indica la
con+eniencia de un enfoque recursi+o- donde los componentes de granularidad
alta se forman con componentes de granularidad inferior- *asta llegar a
componentes mu, peque"os$ (sta situacin- al considerar el proceso de
integracin de componentes , sistemas- lle+a a la p2rdida de fronteras entre las
pruebas de unidad , de integracin- ,a que las pruebas de unidad de un
componente medio corresponden a las de integracin de un grupo de
componentes menores ?Jerum , Sims- &'''A$ (n la seccin siguiente se tratarn
por ni+el- suponiendo que en un momento dado se pueden separar- al menos
conceptualmente$
2.(.2 ,r"ebas e "nia
!ara utiliar un componente debe estar probado$ (ste *ec*o es ms urgente si el
componente es de tipo comercial$ 4*ora bien- los desarrolladores de componentes
=;
deben probarlos- pero tambi2n quienes los integrarn en una aplicacin deben
*acerlo- ,a que no *a, una garanta absoluta de calidad$ Las pruebas de un
componente en su desarrollo inclu,en los diferentes ni+eles# unidad- integracin ,
a)n sistema$ !ero una +e constituida en componente se requerirn pruebas de
unidad por parte de quien la integrar en una aplicacin$ 4s pues- esta seccin
muestra algunos esfueros en relacin con pruebas de unidad para componentes-
ad+irtiendo de antemano que no *a, muc*a informacin sobre el tema$
Como se *a mencionado antes- uno de los modelos ms e0itosos para el
desarrollo de componentes es Ja+a %eans$ La compa"a S3@- desarrolladora
original de Ja+a- cuenta con un procedimiento de certificacin$ !or otra parte- todo
el modelo descansa sobre la mquina +irtual Ja+a- que tiene- entre otras
funciones- la de +erificar cada clase que se in+oca- para asegurarse que cumpla
una serie de requisitos$ Como e0isten +arias mquinas +irtuales de Ja+a- e0isten
tambi2n di+ersos +erificadores$ (n la 3ni+ersidad de Cas*ington se realia el
pro,ecto Uimera ?Sirer- ;::=A- que *a logrado a+ances interesantes sobre la
prueba de mquinas +irtuales$ %ertrand Me,er- por otra parte- encabea un
pro,ecto de aseguramiento de calidad$
Certi$icacin de c"#!"nentes >a&a +eans*
(n forma similar con la FMG- S3@ enfoca la prueba de componentes en relacin
con la conformidad- en este caso dando preferencia a la independencia de la
plataforma$ De *ec*o- las pruebas e0igidas para lograr la certificacin aJa+a ;''b
puroa ?S3@- ;::EA requiere que sea e1ecutado un programa +erificador ,
proporcionar un guin de prueba que permita +erificar que el comportamiento del
componente sea igual , que no se interrumpa su e1ecucin en al menos tres
plataformas$ (l documento insiste que no se refiere a pruebas de calidad ni de
rendimiento$
!or otra parte- sin ser especficas para componentes- Sun ofrece tres
*erramientas de prueba .Ja+a Star- Ja+a Spec , Ja+a Scope/ que se enfocan a
pruebas de unidad- inclu,endo la interfa- pre , post condiciones para cada
funcin , prueba estructural con cobertura de enunciados , de ramas .no
consideran caminos bsicos/$ !ara ms informacin sobre las *erramientas
consulte el sitio de Sun test;' $
Trusted C"#!"nents*
%ertrand Me,er , su compa"a- en colaboracin con C$ Mingins , J$ Sc*midt de la
3ni+ersidad de Monas* *an iniciado un pro,ecto de e+aluacin de componentes
donde pretenden apro+ec*ar su e0periencia en el desarrollo de bibliotecas de
clases para (iffel$ Los puntos ms rele+antes del pro,ecto- conocido como #rusted
$omponents- son los siguientes .tomados de ?Me,er et al- ;:::A/#
;' *ttp#VVwww$sun$comVsuntestV
=&
H se plantean seis bases de confiana en componentes- que son# dise"o por
contrato- +alidacin formal- orientacin a ob1etos , reuso- escrutinio p)blico-
prueba e0tensi+a , esfueros en m2tricas$
H se listan una serie de tareas a realiar- entre las que se destacan la n)mero
># Desarrollar tecnologa de prueba para componentes reusables-
inclu,endo estndares para describir casos de prueba , procedimientos de
prueba$
H adicionalmente- en su pgina Ceb se inclu,e la acti+idad de desarrollar
t2cnicas de especificacin- +erificacin- aseguramiento de calidad-
administracin , prueba de componentes ?Trusted Components- ;:::A$
(ste pro,ecto a)n est en sus comienos- por lo que solamente se tienen sus
propsitos- aunque es e+idente la importancia que se da al tema de pruebas$ Sin
embargo- debe notarse la enorme distancia entre su propsito de contar con
escrutinio p)blico , la realidad de los componentes comerciales- fuertemente
encapsulados$
Prueba !"r tercer"s*
3na forma de lograr confiabilidad para los componentes a reutiliar es su prueba
por un tercero- con caractersticas que lo *agan merecedor de confiana- por sus
m2todos de prueba bien definidos , el uso de estndares$ Seg)n Councill
?Councill- ;:::A- este enfoque de prueba resulta ms )til que los enfoques de
madure del tipo de CMM del S(5 , de la adaptacin a componentes realiada por
el Grupo %utler;;$ (sta afirmacin es +lida sobre todo para empresas peque"as-
que son la gran ma,ora$ Como referencia cita a los 3nderwrite Laboratories;&-
empresa dedicada a la prueba de mu, di+ersos productos , a la produccin de
estndares- que est traba1ando sobre la prueba de componentes de software$
(l enfoque de certificacin *a sido tratado formalmente por De+anbu , Stubblebine
?De+anbu , Stubblebine- &'''A quienes consideran que las compa"as
desarrolladoras de software no desean *acer p)blica la implementacin especfica
de sus productos- ni siquiera a una compa"a dedicada a pruebas$ (sta situacin
se e0tiende a di+ersas posibilidades indirectas- como ane0ar casos de prueba o
de1ar tablas de smbolos- que permitiran ingeniera en re+ersa- al menos parcial-
del producto$ !or otro lado- la compa"a probadora con acceso a informacin
limitada podra ser enga"ada acerca del grado original de pruebas$ Los autores
del citado traba1o desarrollan una serie de opciones ligadas con criptografa
aplicada al producto , a las pruebas realiadas- de modo que puedan +erificarse
sin di+ulgar la implementacin$ (n resumen- es una situacin complicada , que
probablemente tardar en ser ampliamente aceptada$
!or otro lado- en aplicaciones industriales- 8oas sugiere que la certificacin de un
componente slo tiene +alor en relacin con una aplicacin , no en forma general
?8oas- ;::= bA$
;; 8er *ttp#VVwww$butlergroup$co$u7$
;& 8er *ttp#VVwww$ul$com$
=<
2.(.( ,r"ebas e integracin
Las pruebas de integracin son aquellas que analian el comportamiento de +arias
unidades en interaccin$ Se aplican desde dos unidades *asta todo el sistema-
+ariando as el foco de atencin , el alcance de la prueba- correspondiente al ni+el
siguiente$
4unque ,a se *a insistido en la necesidad de pruebas de integracin en general ,
de la necesidad de probar el software basado en componentes- no est por dems
insistir en la importancia que re+isten en este tipo de software los a0iomas de
Ce,u7er- tratados en la seccin &$;$< ?Ce,u7er- ;:=D , ;:==A- en especial los tres
que se relacionan con composicin , definicin de software por especificaciones
sin considerar la implementacin# antie0tensionalidad- antidescomposicin ,
anticomposicin$
(l a0ioma de antie0tensionalidad 1ustamente se aplica a los componentes
indi+iduales$ (se a0ioma afirma que para dos programas diferentes que
implementan la misma funcionalidad un con1unto adecuado de pruebas para uno
puede resultar inadecuado para el otro$
(l a0ioma de antidescomposicin se refiere a que un componente probado
adecuadamente en un conte0to puede no ser adecuadamente probado en otro$
(sto se aplica al reuso de componentes$
!or )ltimo- el a0ioma de anticomposicin afirma que la prueba de dos
componentes por separado no garantia que la prueba sea suficiente cuando se
componen$ (sto afecta la base de la composicin de aplicaciones a partir de
componentes , corresponde a la integracin$
(n esta seccin se tratan +arios aspectos caractersticos de la prueba de
integracin de componentes , los a+ances que se *an realiado$
5*:*:*4 Caracter0sticas de )as !ruebas de integracin*
4lgunas caractersticas que con+iene destacar de las pruebas de integracin de
S%C son las siguientes#
a/ relacin con la arquitectura del sistema
b/ necesidad de modelos de composicin , criterios de adecuacin de
pruebas
c/ criterios de adecuacin basados en modelo de composicin
d/ momentos de aplicacin
Re)acin c"n )a ar3uitectura
La importancia de la arquitectura del sistema en las pruebas de integracin-
pro+iene de que destacan los aspectos de interaccin entre componentes- los
cuales son el campo de aplicacin para las pruebas de integracin$ Cuando se
trata de software tradicional no resulta tan rele+ante porque casi toda la
=B
intercone0in es del tipo llamada a funcin- misma que est bien cubierta por
m2todos tradicionales de prueba$ Slo cuando se emplean componentes- con la
comple1idad del software resultante- se *acen e+identes otras formas de
interaccin$
9osemblum *a *ec*o notar ?9osenblum- ;::=A que los modelos arquitectnicos
pueden a,udar de +arias maneras al proceso de prueba de S%C#
a/ !rueba del modelo directamente$
b/ Como gua de pruebas de integracin del sistema implementado-
especialmente en cuanto al orden de prueba$
c/ !uede usarse como gua en pruebas de regresin ante cambios dinmicos$
Sin embargo anota algunos problemas para el uso de descripciones
arquitectnicas en la prueba de software$ 4lgunas son#
H (n algunos casos los conectores pueden +erse como componentes para
fines de prueba- siempre que el lengua1e usado lo permita
H 4lgunos LD4 distinguen ni+eles , el conceptual puede diferir del de
implementacin , puede *aber diferencia entre los dominios de ambos-
generalmente Dconceptual Dimplementacin$
H Los modelos de LD4 inclu,en formas de interaccin ms ricas que las
disponibles por algunos tipos de componentes- por lo que deben mapearse$
(s necesario para ello traba1ar en el modelo de adecuacin$
M"de)ad" de c"#!"sicin ( criteri"s de adecuacin
!ara poder aplicar pruebas satisfactorias se debe contar con criterios de
adecuacin- los cuales suponen alg)n modelo sub,acente de cmo opera el
software , a qu2 se le aplicarn las pruebas$ !or e1emplo- en el caso de pruebas
estructurales con+encionales McCabe supuso un con1unto de caminos potenciales
de e1ecucin , determin que e0ista un con1unto bsico- a partir de lo cual
propuso que basta aplicar pruebas que garanticen el uso de todos los caminos
bsicos ?Catson , McCabe- ;::DA$
!ara el caso del S%C no se *a *ec*o muc*o sobre criterios de adecuacin ni del
modelado de composicin sub,acente- sal+o la aplicacin de los a0iomas de
Ce,u7er ,a mencionados$ 3n traba1o al respecto es el de 9osenblum
?9osenblum- ;::EA- que considera un componente en relacin al sistema que la
contiene , al sistema en relacin a un componente$ 4 continuacin se describen
algunos aspectos del mismo$
Supone que un componente- que se denotar por M- encapsula un cierto estado ,
pro+ee una interfa bien definida que gobierna estrictamente el acceso al estadoI
tal interfa tpicamente es un con1unto de m2todos$
Supone que se reduce la interfa a un solo m2todo que mane1a el acceso a todos
los dems- mediante un parmetro adicional$ (l dominio de entrada de M ser la
=>
composicin de dominios de entrada de los m2todos- adicionados por el
parmetro e0tra$
4 continuacin supone que#
i$ desde el punto de +ista del programa- !- su dominio de entrada se puede
di+idir en dos# uno que atra+iesa M , otro que no$
ii$ desde el punto de +ista del componente M- su dominio de entrada se di+ide
tambi2n en dos# uno que es usado por ! , otro que no$
(ntonces se tiene#
D! # Dominio de entrada de !#
DM #Dominio de entrada de M#
M6tra+erse.D!/# subdominio de D! que atra+iesa M
M6%,pass.D!/# subdominio de D! que no atra+iesa M
!6rele+ant.DM/# subdominio de DM que es usado por !
!6irrele+ant.DM/# subdominio de DM que no es usado por !
4 partir de lo anterior define adecuacin de criterios de prueba basados en
subdominios con comportamiento equi+alente$ Llama C al criterio , entonces
define#
3n con1unto de pruebas TM es C8ae!"ate8for8, si contiene al menos un
caso de prueba para cada subdominio SDC.!6rele+ant.DM//$
3n con1unto de pruebas T! es C8ae!"ate8#it08M si atar+iesa M al menos
un elemento de cada subdominio SDC .!6rele+ant.DM//$
Los subdominios de inter2s estn definidos as#
SDC .!6rele+ant.DM// Q Y D M6tra+erse.D!/ ] DN SDC .DM/
D DN DN6D !6irrele+ant.DM/ D Z
C"ndici"nes #0ni#as
!ara la realiacin de pruebas de integracin se suponen cumplidas tres cosas#
i$ Se *a realiado una re+isin fsica- funcional , ambiental del conte0to
ii$ Los componentes a probar son mnimamente operati+os
iii$ (l software para pruebas es estable .es decir- *a sido probado , no est
cambiando/$
(n el software tradicional la re+isin inicial es relati+amente simple- ,a que
usualmente es un solo equipo , su sistema operati+o$ (n el caso de componentes
se complica por su posible distribucin , por la e0istencia de contenedores- as
como software au0iliar$
=D
La segunda suposicin se ampla un poco respecto de software con+encional-
donde se supone ampliamente probada cada unidad- ,a que algunos aspectos de
la operacin de un componente dependen de su conte0to , debe +erificarse antes
de integrarlo con otros$ Debe recordarse adems que en el S%C las pruebas de
unidad , de integracin tienen una frontera bastante borrosa$
La )ltima suposicin es necesaria tambi2n para garantiar que no se est2n
probando en paralelo la aplicacin , el software de prueba$
La descripcin de estas condiciones puede *allarse en di+ersos autores- como
?%inder- ;:::A$
M"#ent"s de a!)icar)as*
Dentro del ciclo de +ida de S%C e0isten tres momentos principales en los que se
deben realiar pruebas de integracin# al ensamblar- al desplegar ,- si e0isten
componentes dinmicos- al e1ecutar$
(n el ensamble se integran uno o ms componentes ba1o un contenedor ideal$ (n
el despliegue el contenedor se reemplaa por el real donde se e1ecutar la
aplicacin$ (n la e1ecucin pueden cambiar los componentes ,a sea por
actualiacin o por mane1o dinmico$
Las pruebas de integracin se relacionan con +arias etapas del ciclo de +ida del
S%C# inicialmente al tiempo de ensamblado se debern probar las relaciones
establecidas entre los componentes mismosI luego- al tiempo de despliegue- se
debern probar las relaciones entre componentes , contenedores , entre 2stos ,
los ser+idores o plataforma$ Finalmente- en algunos casos se deber probar en
forma dinmica al tiempo de e1ecucin$
(n la prctica- las ms rele+antes sern las pruebas al tiempo de e1ecutar cuando
e0istan aspectos dinmicos- pero la ms necesaria ser al tiempo de despliegue$
Slo en ese momento se pueden probar adecuadamente una unidad en el
ambiente donde +a a operar , grupos de componentes con los conectores ,
ser+icios que las complementarn$
@ecesidades , caractersticas en cada momento$
!ara las pruebas de integracin en cada momento se tienen necesidades ,
caractersticas diferentes#
a/ A) tie#!" de ensa#b)e# pueden super+isarse , a)n aplicarse manualmente-
,a que se tiene un ambiente controladoI se aplica principalmente a los
componentes estables en el sistema- que qui sean los ma,ores$ (sto inclu,e
tambi2n al contenedor propuesto para la aplicacin$ Sern pruebas que
pueden llamarse estticas$
b/ En e) des!)iegue# el 2nfasis estar en la interaccin con los contenedores
reales- que debern satisfacer las necesidades establecidas en el ensamble$ Si
=E
el contenedor es el mismo- se confunden con las anteriores$ (stas pruebas son
ms susceptibles de automatiacin- ,a que puede *aber +arias copias de la
aplicacin$ Se aplican dominantemente a los componentes estables$
c/ En )a e6ecucin; cuando e0isten componentes dinmicos- se debe poder
probar la integracin del componente al con1unto$ Son pruebas dinmicas- por
lo cual tendrn que estar no slo automatiadas- sino integradas- ,a sea con la
aplicacin o como un ser+icio para la misma$ !ueden incluirse ser+icios
temporales para alg)n componente igualmente temporal$ (n estas pruebas no
+aran los componentes estables .e0cepto que *a,a un cambio de +ersin/- por
lo cual el 2nfasis estar en la interaccin entre 2stos , los componentes
transitorios$
5*:*:*5 E8!eriencias re!"rtadas
(0iste poca informacin acerca de prueba de S%C como tal- especialmente del
ni+el de integracin$ Los libros acerca de componentes- inclu,endo los de tipo
comercial .soporte de alguna plataforma/ lo tratan- cuando ms- a la ligera$ (l
primer te0to rele+ante que inclu,e el tema de pruebas es el libro de Jerum ,
Sims ?Jerum , Sims- &'''A- sin demasiada profundiacin$
Se puede ampliar la informacin con obras relacionadas- dedicadas a sistemas de
empresa- a)n cuando no sean especficamente de componentes- como el libro de
Mosle, ?Mosle,- &'''A- pero sus conceptos son mu, generales , con bases
relati+amente anticuadas$
4 continuacin se presentan algunos reportes especficos acerca de pruebas ,
componentes$
Una e8!eriencia !r"b)e#,tica*
Garlan , sus colaboradores ?Garlan et al- ;::>A reportan una e0periencia de
integracin de componentes , su anlisis de las dificultades encontradas$ (l
pro,ecto pretenda realiar una *erramienta para el mane1o de estilos
arquitectnicos , planeaba utiliar cuatro elementos disponibles en el mercado ,
que supusieron compatibles# un mane1ador de bases de datos FF- un constructor
de interfaces- un mecanismo de 9!C , uno de difusin de e+entos$ Los dos
primeros 1uegan el papel de componentes en sentido arquitectnico , los dos
)ltimos el de conectores$ (l pro,ecto se plane para seis meses , un a"o *ombre
, se termin en dos a"os , cinco a"os *ombre- logrando apenas un prototipo lento
, +oluminoso- difcil de mantener$
(n el anlisis que *acen los autores atribu,en muc*os de los problemas a
incompatibilidades de tipo arquitectnico entre los di+ersos elementos
incorporados- que pueden resumirse as#
H Los componentes seleccionados inclu,en elementos innecesarios para el
pro,ecto- que contribu,en a que la solucin sea +oluminosa , lenta$
==
H (l modelo de control- aunque similar en lo e0terior- basado en e+entos-
result incompatible en su implementacin$
H Los modelos de datos- tanto en la 1erarqua de ob1etos como en el paso de
parmetros- resultaron conflicti+os por estar basados en suposiciones
diferentes$
(ntre sus recomendaciones como solucin a largo plao se pueden anotar#
H Jacer e0plcitas las suposiciones arquitectnicas$
H 3tiliar subcomponentes peque"os , ortogonales , a partir de ellas crear
otros ma,ores$
H !ro+eer t2cnicas para lograr la comunicacin a pesar de las posibles
incompatibilidades- usando wrappers o con componentes , conectores ms
+erstiles- con interfaces negociadas$
H Desarrollar fuentes de asesora en dise"o arquitectnico- que inclu,an#
*eursticas- reuso de patrones de dise"o- ambientes de desarrollo ,
*erramientas por dominio$
M1t"d" sugerid" !"r V"as*
Jeffre, 8oas es uno de los desarrolladores , autores ms dedicado al tema de los
componentes- sobre el cual *a publicado di+ersos artculos$ Su compa"a
.9eliable Software Tec*nologies/ mantiene muc*os esfueros sobre el tema$ (n
su traba1o ?8oas- ;::= bA 8oas supone que los componentes +ienen
encapsulados- sin tener acceso al cdigo fuente- proponiendo una serie de pasos
para certificarlos#
i$ 8erificar la funcionalidad ofrecida por el componente- determinando si
satisface lo requerido por el dise"ador$ Si se cumple esta parte- se pasa a
las siguientes que son#
ii$ 9e+isar la calidad del componente- bsicamente con pruebas de unidad- de
ca1a negra$ Los casos de prueba se preparan de acuerdo al perfil
operacional pre+isto$ Sus resultados dependern de la calidad de los
orculos$
iii$ 5mpacto positi+o del componente sobre la aplicacin$ (n esta etapa se
+erifica el componente dentro de la aplicacin- in,ectando defectos en los
parmetros que pasan a , desde el componente- de modo que se puede
estimar el peor caso de comportamiento de la aplicacin en relacin a ese
componente$ (sta es una prueba de sensibilidad$ !uede suceder que un
componente de calidad mediana tenga un efecto positi+o sobre la
aplicacin , entonces se la puede considerar- especialmente si no *a,
componentes alternos$ Tambi2n puede suceder que un componente de
calidad produca un efecto negati+o$ La in,eccin de defectos corresponde
a una t2cnica de perturbacin conocida como %nterface &ropagation
'nalysis (%&') , consiste en alterar aleatoriamente alguno de los datos que
pasan por la interfa$ (n su traba1o )nicamente se perturban datos
num2ricos , cadenas alfanum2ricasI no se inclu,en apuntadores ni ob1etos$
=:
i+$ 4 ni+el de integracin- adems de la etapa anterior- se recomiendan
pruebas operati+as para obser+ar el comportamiento de la aplicacin en
circunstancias normales$ (sta prueba puede ser larga si no *a, muc*as
fallas$
(l autor *ace notar que- por la naturalea de las pruebas de ca1a negra- pueden
quedar aspectos no e+aluados- como funcionalidades ocultas , a)n maliciosas-
como Caballos de Tro,a$
5*< Resu#en
(n este captulo se *an analiado conceptos bsicos de prueba de software-
enfatiando las pruebas de integracin$ Luego se analiaron elementos de prueba
de software orientado a ob1etos- por su fuerte relacin con el software de
componentes$ Finalmente- la parte principal del captulo present los a+ances en
pruebas , especialmente pruebas de integracin de software basado en
componentes- inclu,endo algunos elementos para formaliar criterios de prueba$
De todo 2sto- los aspectos ms rele+antes por su uso directo en el resto del
traba1o son#
H Concepto de estrategia de prueba funcional- rele+ante al considerar el
encapsulamiento del software basado en componentes$
H 5mportancia de las ta0onomas de defectos como manera de saber qu2 se
busca en las pruebas$
H 40iomas de Ce,u7er- especialmente los de antie0tensionalidad-
anticomposicin , antidescomposicin$
H 5mportancia de las pruebas de integracin$
H De la orientacin a ob1etos- su importancia por ser el enfoque preferido al
desarrollar componentes modernos , m2todos de prueba que podran
e0tenderse a componentes- en especial los propuestos por %inder$
H Diferencias importantes del S%C que *acen necesario considerar sus
pruebas de manera particular$
H Sugerencias de 8oas en relacin con el efecto de un componente sobre el
resto de la aplicacin$
H Sugerencias de 9osemblum acerca de la relacin entre la arquitectura , las
pruebas de integracin , sus criterios de adecuacinI tambi2n el mane1o de
composicin entre aplicacin , componente como una forma de agregacin$
Los elementos anteriores sern retomados dentro de los captulos siguientes que
corresponden a la propuesta contenida en el traba1o$
:'
Ca!0tu)" : M"de)ad" de s"$t%are
basad" en c"#!"nentes
Los captulos anteriores presentaron un panorama del estado del arte acerca de
software basado en componentes , acerca de la prueba de software-
particularmente del S%C$ (n este captulo se precisa la manera en que se
modelar el software basado en componentes para ser+ir a los propsitos del
traba1o- , se detalla qu2 se entender por componentes ba1o la plataforma elegida$
Se comenar con algunas definiciones , luego se e0aminan las caractersticas
deseables en un LD4 para modelar componentes$ 4 continuacin se detallar el
tipo de lengua1e descripti+o de arquitectura que se emplear- el cual ser una
e0tensin de 3ML que se denomin Ar!"ipp$ !osteriormente se detallarn los
elementos de la plataforma Ja+a & que sern mane1adas como componentes en
este traba1o- inclu,endo e1emplos de modelado de los mismos usando 'ruipp$
Finalmente- se presenta el modelado de una peque"a aplicacin para e1emplificar
todos los pasos necesarios$
!artes de este captulo se presentaron en ?Fernnde- &''' aA- ?Fernnde- &'''
cA , ?Fernnde- &'';A$
:;
:*4 De$inici"nes
(n esta seccin se presenta una serie de definiciones que sern necesarias en lo
que resta del traba1o$ Descansan en los elementos discutidos en los captulos
anteriores$
(.1.1 Componente
3n componente es un elemento- de proceso encapsulado o de datos- que se
despliega independientemente- se caracteria por una funcin especfica e
interfaces requeridas , ofrecidas- est dise"ado para combinarse con otros
componentes formando aplicaciones , puede presentar propiedades modificables
al tiempo de despliegue$
(ntre las propiedades modificables al tiempo de despliegue se tienen los plug*ins,
que son peque"os componentes au0iliares que le agregan funcionalidad a un
componente ma,or$
(.1.2 Conector
(lemento arquitectnico que representa la interaccin entre dos o ms
componentes$ Su implementacin puede ocurrir como un componente fsico- como
elementos de ser+icio en software intermedio o como parte de los mecanismos del
sistema operati+o$
Dado que un conector puede implementarse como componente fsico- con+iene
establecer un criterio de distincin- aunque ser el desarrollador quien debe
decidirlo en definiti+a$ Si se considera un conector como componente- obligara a
considerar )nicamente interacciones de ni+el ba1o- como llamadas a subrutinas o
in+ocacin de m2todos$ !ara este traba1o se propone como criterio diferenciador el
siguiente# si un elemento *ace funciones de comunicacin entre otros elementos ,
es parte de la plataforma o software intermedio que se utiliar .fuera del mbito
de decisiones del desarrollador/- se le tratar como conector$ Si un elemento *ace
funciones de proceso o de datos , depende totalmente del desarrollador- se le
tomar como componente$
(.1.( Aplicacin %aplicacin e soft#are basao en componentes'
Sistema de cmputo constituido por un grupo de componentes que interact)an
para lograr ob1eti+os especficos$
!ara caracteriar una aplicacin se emplea una descripcin arquitectnica- la cual
inclu,e- al menos- el con1unto de componentes que la forman- el con1unto de
conectores que permiten la interaccin entre ellos , la descripcin de la
conecti+idad entre los elementos anteriores$
:&
(.1.) Conteneor
(n los modelos comerciales de componentes se considera que estos operan
dentro de un contenedor- que es una piea de software que los pro+ee de
ser+icios , soporte para la administracin de recursos$ De este modo- un
contenedor es un intermediario entre el componente , la plataforma$
Comercialmente forman parte de lo que se llama software intermedio
.middleware/$
Desde un punto de +ista arquitectnico- un contenedor ofrece- como parte de sus
ser+icios- uno o +arios conectores bsicos a los componentes que contiene$
(.1.4 ,lataforma
Con1unto de elementos de *ardware , software que conforman la base operati+a
general para aplicaciones especficas$ !or la parte de *ardware inclu,e
procesadores- memoria- dispositi+os de entrada- salida , almacenamiento , redes$
!or el lado del software se inclu,e el sistema operati+o- software de red- mquinas
+irtuales , bibliotecas$
(.1.5 /oft#are intermeio
Con1unto de software que permite crear aplicaciones a partir de familias de
elementos estndar$ (s una capa sobre la plataforma bsica que ofrece ser+icios
para crear aplicaciones de empresa$ 3no de sus elementos son los contenedores
para los componentes$
:*5 Una descri!cin ar3uitectnica !ara e) S+C
(n los captulos anteriores se *a discutido la naturalea del software basado en
componentes .S%C/ , su relacin con el modelado arquitectnico$ Tambi2n se *an
tratado diferentes aspectos de la prueba de software- enfatiando la prueba de
integracin- que es el tema de este traba1o$ (n esta seccin se precisa la
necesidad de un lengua1e descripti+o de arquitectura .LD4/ para el S%C- que sir+a
como base para preparar pruebas de integracin$
(.2.1 -ecesia e "n $&A
(l software comple1o- como es el caso del S%C- requiere un dise"o arquitectnico
que permita analiar al sistema a)n antes de su implementacin$ Los modelos
arquitectnicos se constru,en para raonar acerca del sistema , apo,arse en ellos
para el desarrollo$ Sin embargo- e0isten di+ersos ob1eti+os posibles para realiar
modelos arquitectnicos$ (n algunos casos se trata de un dise"o mu, abstracto-
)til para una +isin integral del sistema$ Muc*as +eces estos modelos no
correspondern con la implementacin$ Ftros modelos se realian para generar
automticamente el software o para analiar su funcionamiento$ (n algunos casos
los modelos pueden corresponder con la implementacin$
:<
(l dise"o arquitectnico- en cualquiera de sus ni+eles- necesita un lengua1e
adecuado para e0presarse- de modo que resulte de utilidad en el raonamiento
acerca de un sistema$ 3na de las aplicaciones de este modelado es la preparacin
de pruebas- especialmente de integracin$ Debe recordarse que el modelado
arquitectnico , las pruebas de integracin tienen como aspecto com)n el inter2s
por estudiar la interaccin entre componentes$
La preparacin de pruebas de integracin se centra en la interaccin de
elementos$ (n el caso de software basado en componentes- la prueba de
integracin se relaciona con la interaccin entre componentes$
4)n antes de que se establecieran los conceptos modernos de arquitectura de
software- se empleaba la descripcin estructural de un sistema como gua de las
pruebas de integracin$ 4s pues- es raonable partir del modelado arquitectnico
para preparar pruebas de integracin de S%C$
4*ora bien- cada LD4 se orienta a alg)n uso particular donde ofrece ma,ores
+enta1as$ (n el caso de este traba1o- se busca un LD4 que sea de utilidad para
pruebas de integracin$
(n las siguientes subsecciones se caracteria el LD4 deseado , las alternati+as
para contar con uno$
(.2.2 Caractersticas !"e ebe satisfacer
!ara contar con una descripcin arquitectnica )til para pruebas- el formalismo
empleado debe satisfacer- adems de las cuatro caractersticas de un LD4
tratadas en la seccin ;$&$&$;- algunas caractersticas- que se e0aminan a
continuacin#
Consideraciones acerca del desarrollador#
Los desarrolladores- en su ma,ora- mane1an formalismos de modelado del tipo de
3ML$ (stos le permiten cubrir la ma,ora de las etapas de desarrollo de software$
Sin embargo- las presiones de los empleadores , el mercado les impiden el uso de
*erramientas ms formales- entre las que se cuentan los LD4$
3na de las raones del 20ito de 3ML es la cercana con las t2cnicas de modelado
que se *an desarrollado a lo largo de muc*o tiempo , que- por lo mismo-
necesitan poco tiempo para su estudio , aplicacin$
!or otra parte- los formalismos que usa un desarrollador deben ser relati+amente
sencillos- orientados a sus propsitos concretos$ 4l modelar deben incluirse
)nicamente los elementos necesarios$ 3na e0tensin de este *ec*o refuera la
definicin de conector que se dio en <$;- ,a que no debe requerirse el modelado
de elementos fuera del control del propio desarrollador$
:B
Concretando se resume en que los formalismos#
H Sean sencillos- cercanos al traba1o diario del desarrollador
H Modelen )nicamente los elementos ba1o su control
Consideraciones acerca del formalismo con relacin al proceso de prueba#
(n cuanto a caractersticas de apo,o al proceso de pruebas- un LD4#
H Debe destacar la interaccin entre componentes$
H Debe permitir generar casos de prueba adecuados$
H Con+iene incluir el perfil de uso de los componentes$
H !ermitir descubrir interacciones no e+identes$
Las dos primeras consideraciones no necesitan comentario- ,a que son parte del
proceso de prueba de integracin$
La tercera es necesaria para dar ms 2nfasis a las partes ms utiliadas en un
sistema- especialmente si los casos de prueba se elegirn al aar- de entre el
con1unto de casos que formen un con1unto adecuado$ Si no se tiene esa
informacin- se puede reemplaar por una distribucin uniforme$
La )ltima se refiere a elementos que a +eces quedan implcitos , el desarrollador
puede no estar conciente de ellos- pero que influ,en sobre el proceso de prueba$
!or e1emplo- el uso de (J% in+olucra arc*i+os de datos de despliegue que pueden
originar acoplamientos no pre+istos$
Ftras consideraciones#
4dems de las caractersticas deseables mencionadas- con+iene anotar algunas
consideraciones importantes para acotar el alcance del LD4 propuesto#
H @o ser para estudiar arquitecturas ni LD4$
H @o se busca que genere sistemas automticamente$
Las consideraciones no niegan el +alor de considerarlas como ob1eti+os en otras
circunstancias$
(.2.( Alternativas e sol"cin
!ara la realiacin de un LD4 que sea de utilidad para pruebas- puede elegirse
entre di+ersas alternati+as- a e+aluar con los criterios antes establecidos$ Las
principales son#
a/ Seleccionar un lengua1e descripti+o de arquitectura ,a establecido- como
podra ser Crig*t$
b/ Seleccionar un lengua1e de modelado de amplia difusin entre los
desarrolladores$
c/ Desarrollar un lengua1e especfico- dise"ado especialmente para el casoI
d/ 4daptar un lengua1e de modelado e0istenteI en este caso *abra que
distinguir si se de1a tal cual o se e0tiende o modifica$
:>
3n bre+e anlisis arro1a estos resultados#
Seleccin de un LD4 establecido# esta alternati+a tiene como positi+o su difusin ,
e0istencia de *erramientas- as como la posibilidad de emplearla para otros
ob1eti+os adems de la prueba$ !or el lado negati+o se tiene que no cumple con
las caractersticas propuestas- especialmente por no ser de uso com)n entre
desarrolladores$ 4dems- los LD4 ms conocidos no cuentan con elementos
especficos para el desarrollo de casos de prueba- por lo cual debieran
e0tenderse$
Seleccin de un lengua1e de modelado difundido entre desarrolladores# esta
alternati+a resulta inapropiada- ,a que los lengua1es de modelado no contienen
todos los elementos necesarios para utiliarlos como LD4$ 3ML- uno de los
lengua1es de modelado ms completos , ms difundidos en la actualidad- carece
de algunos elementos como son#
H el concepto de componente de 3ML es ms bien para implementacin que
para dise"oI tiene una semntica +aga , se traslapa con otros
clasificadores ?Uobr,n- &'''A
H al concepto de componente de 3ML no se aplican muc*as relaciones del
propio 3ML , no participan en diagramas de interaccin ?Garlan et al- ;:::A
H si se usan como elemento de modelado arquitectnico no *a, buenas
opciones para puertos , conectores- seg)n la comparacin que aparece en
?Garlan et al- ;:::A
H el concepto de puerto no e0iste en 3ML , no se puede igualar con el de
interfa- ,a que aquel puede incluir implementacin ?Selic , 9umbaug*-
;::=A
H el concepto de conector no e0iste en 3MLI no basta la asociacin entre
componentes$
Desarrollar un lengua1e especialmente dise"ado# esta alternati+a puede
representar mu, apropiadamente los elementos necesarios para pruebas ,
representa una mu, buena opcin a largo plao$ Sin embargo- el tiempo necesario
para su desarrollo , difusin entra en conflicto con las necesidades actuales , con
lo cambiante del mbito de software basado en componentes$ (sta situacin
dificultara su desarrollo , producira a+ances rpidamente obsoletos- lo cual sera
aceptable si el ob1eti+o es estudiar S%C o arquitecturas de software- pero no si se
trata de desarrollar pruebas para software real$
(sta alternati+a- en el corto plao no es con+eniente- aunque s a largo plao$
4daptacin de un lengua1e de modelado en uso por desarrolladores# esta
alternati+a tiene a su fa+or el que ,a es conocido por los desarrolladores , por lo
mismo contara con *erramientas de apo,o$ (n un sentido general tiene el
problema de carecer de elementos especficos para el modelado arquitectnico- lo
cual es especialmente gra+e cuando se usan modelos a gran ni+el de abstraccin
, para raonar acerca de su correccin$ (n el caso presente- estando ms cerca
:D
de la implementacin- la diferencia ser menos gra+e$ Debe considerarse-
adems- que generalmente carecen de orientacin a pruebas$
(n esta alternati+a e0iste una opcin dominante- que est con+irti2ndose en un
estndar- , es 3ML$ 4*ora bien- como di+ersos autores .por e1emplo ?9obbins et
al- ;::=A- ?Med+ido+ic et al- &'''A , ?Garlan et al- ;:::A/ lo *an mostrado- 3ML no
es suficiente para la descripcin arquitectnica- pero puede ampliarse de modo
que resulta )til$
(0isten +arias formas de adaptar 3ML para representar componentes$ 4lgunas
simplemente adaptan lo que e0iste empleando estereotipos- sin agregar
elementosI ms bien e0tienden la semntica de algunos$ 4l respecto *a, di+ersas
posibilidades- todas las cuales tienen sus +enta1as , des+enta1as- como lo
muestran Garlan , 4llen ?Garlan et al- ;:::A$
Con la adopcin de 3ML , sus mecanismos de e0tensin se puede lograr un LD4
apropiado para pruebas- en un tiempo corto- para satisfacer las necesidades de
pruebas de integracin por un tiempo$
(n este traba1o se eligi agregar un perfil .profile/ especfico$ (sta alternati+a
permitir representar componentes en el sentido que se estn considerando , ser
de especial utilidad- pero no )nica- en la generacin de pruebas$
:*: Ar3ui!!
La solucin elegida fue desarrollar un lengua1e descripti+o de arquitectura como
una e0tensin a 3ML$ (n esta seccin se presentan los elementos agregados al
metamodelo de 3ML , los aspectos propios de la notacin que se modifican$ Su
e0amen ms amplio se presenta en la siguiente seccin$
(.(.1. &escripcin
(ste documento presenta una propuesta de e0tensin a 3ML denominada
Ar!"ipp$ Tal e0tensin constitu,e- 1unto con 3ML- un lengua1e descripti+o de
arquitectura que se orienta a describir aplicaciones basadas en componentes- as
como elementos tpicos- tanto de componentes como de conectores$ (l propsito
principal de Ar!"ipp es brindar una base arquitectnica para deri+ar pruebas de
integracin para las aplicaciones descritas con el mismo$
(n el desarrollo de 'ruipp se tu+ieron en cuenta dos criterios para mantenerlo
mane1able#
a/ Se busca la sencille de representacin- para e+itar complicar
innecesariamente la descripcin de aplicaciones$
b/ Se pretende modelar , un modelo no es )nico ni pretende ser el me1or$
(n caso de duda- se modela seg)n las necesidades$
(.(.2. *9tensiones necesarias como prerre!"isitos
:E
(sta e0tensin no requiere otras como prerrequisitos$
(.(.(. *stereotipos
(n esta seccin se define la lista de estereotipos que constitu,en la e0tensin$ (n
la Figura <$; se muestra grficamente la relacin de los estereotipos con 3ML ,
sus ni+eles de modelado$ 4lgunos elementos parecen repetidos por la necesidad
de mostrar la relacin con otros$
Clase
ee(stereotipoff
Lnea
ee(stereotipoff
Componente
Meta Modelo
(0tendido
Meta Modelo
ee(stereotipoff
!uerto
ee(stereotipoff
!uerto
Clase de
4sociacin
ee(stereotipoff
Conector
Meta Modelo (0tendido
Meta Modelo
ee(stereotipoff
Lnea
Clase
ee(stereotipoff
(nlace
Figura <$;$ (0tensin propuesta por ni+el de modelado$
Estere"ti!"
@ombre# !uerto
Clase del Metamodelo# Clase
Semntica# representa una terminal de comunicacin de un componente o
conector con el mundo e0terior$ Fcurre en la frontera de alg)n componente
o como terminal de un conector , est formado por una o ms lneas de
entrada o salida$ !ueden agregarse puertos predefinidos a diferentes
componentes$
Sinta0is .notacin/ icono# se puede representar como un rectngulo relleno
sobre el borde de un componente .+er Figura <$&/$ (n los conectores no se
representa grficamente$
!ropiedades de restriccin# debe incluir al menos una lnea$
!ropiedades de +alores etiquetados#
:=
Natura)e'a# indica la naturalea del puerto- que puede ser ofrecido-
si corresponde a funcionalidad del componente propietario del
puerto- o reuerido si corresponde a funcionalidad de otros
componentes que es necesaria para su funcionamiento$
Figura <$& 5cono de puerto
Dos puertos son compatibles si son de naturalea complementaria , e0iste un
con1unto de lneas comunes- con mismo tipo , papel complementario$ Dos puertos
son complementarios si son compatibles , tienen el mismo con1unto de lneas$ Las
llamadas KtecnologasL de una plataforma se traducen- entre otras cosas- en
con1untos de puertos$ Dado un puerto con su nombre- un puerto complementario
se puede identificar por el nombre precedido del smbolo KWL$
(l puerto representa un concepto abstracto que ser id2ntico en componente ,
conector- por sencille de representacin$ Se +isualian como enc*ufes grandes-
con muc*as posibles lneas$ @o se separa en interfa , en implementacin porque
eso trae connotacin especfica de implementacin , aqu se le mane1a a ni+el
ms abstracto$
Estere"ti!"
@ombre# Componente
Semntica# 9epresenta una piea de software encapsulado que puede
desplegarse independientemente , que est descrita en un ni+el funcional$
Consiste en uno o ms puertos- algunas propiedades , un con1unto de
reglas que definen su funcionalidad- e0presadas como pre ,
postcondiciones escritas en FCL- que e0presan relaciones entre lneas ,
propiedades$ 4 un componente se pueden agregar puertos$
Sinta0is .notacin/ icono# clase con estereotipo , puertos sobre su frontera
.+er Figura </
!ropiedades de restriccin# al menos debe incluir un puerto , el con1unto de
reglas no debe ser +aco$
Se)eccin# indica si el componente se selecciona est+ticamente- en
forma din+mica al tiempo de e1ecucin o por seleccin al tiempo de
despliegue$ @o debe quedar +aca esta propiedad$
Ada!tacin# indica si el componente puede adaptarse al tiempo de
despliegueI si el +alor es ninguna- no se modificaI despliegue indica
que se indica en el proceso de despliegue , archivo indica que los
datos de adaptacin se describen en un arc*i+o- cu,o nombre se
indica en la propiedad 4rc*6adapta$
::
Arc2Eada!ta# en caso de adaptacin a tra+2s de arc*i+o- indica el
nombre del mismoI en otro caso se escribe vac,o$
eecomponenteff
Compo[
puerto
Figura <$< 5cono de componente
Estere"ti!"
@ombre# Lnea
Semntica# representa un punto de enlace entre el puerto de un
componente , su correspondiente en otroI la cone0in se realia a tra+2s
de un conector$
Sinta0is .notacin/ icono# ningunaI de *ec*o no se representa grficamente-
,a que se integra con el puerto$
!ropiedades de restriccin#
Pa!e)# indica si la lnea se utilia como entrada- como salida o mixta si tiene
ambas formas de usarla$
Ti!"# denota la naturalea del tipo de datos- que puede ser uno
especfico o gen2ricoI los +alores corresponden a los aceptados en la
aplicacin$
Dos lneas son complementarias si usan el mismo tipo de datos , su papel es
complementario- de acuerdo con la siguiente asignacin# entrada es complemento
de salida , +ice+ersa- mi0ta es complementaria de s misma$
Estere"ti!"
@ombre# (nlace
Semntica# 9epresenta una cone0in simple entre dos puertos en distinto
componente o entre un puerto en un componente , el propio conector$ (n el
primer caso ser un enlace de comunicacin , en el segundo un enlace de
control$
Sinta0is .notacin/ icono# ninguno- porque ser parte de un conector$
;''
Categ"r0a# indica si el enlace ser de comunicacin o de control
Estere"ti!"
@ombre# Conector
Clase del Metamodelo# Clase de asociacin
Semntica# 9epresenta una asociacin entre dos componentes que
describe la interaccin entre ambas$ 3sualmente enlaa un puerto en cada
componente , ambos resultan complementariosI estos son enlaces de
comunicacin$ (n algunos casos es necesaria la e0istencia de otros
enlaces$ Tambi2n pueden e0istir cone0iones entre un puerto en un
componente , el propio conector- para fines de control$ Dado que es una
clase de asociacin- su multiplicidad debe ser uno$ 3n conector est
formado por uno o ms enlaces$ Como representa una forma de
comportamiento interacti+o- 2ste debe e0presarse por uno o ms de los
elementos siguientes# reglas en FCL- diagrama de estados- diagrama de
acti+idades- diagrama de secuencia o de interaccinI preferente se
utiliarn diagramas de secuencia$
Sinta0is .notacin/ icono# un conector es una clase de asociacin- pero por
simplicidad puede representarse como una lnea doble con el estereotipo ,
nombreI en caso e0tremo se puede reducir a lneas de diferentes colores
para cada tipo de conector- cuando la legibilidad de diagramas lo e0i1a$ 8er
Figura <$B$
L"ca)idad# indica la relacin entre el conector , el medio fsico donde
reside- pudiendo ser# local al proceso que in+olucra a los
componentes conectados- euipo- si reside en el mismo equipo-
aunque no en un mismo proceso , red si se conectan componentes
que residen en diferentes equipos$
(n un sentido semntico- un conector es una implementacin .en una plataforma
particular/ de un protocolo general$ !or e1emplo- el mecanismo de e+entos entre
Ja+a%eans es un conector especfico que responde a un protocolo general de
comunicacin a tra+2s de e+entos$
!or simplicidad del modelado- aunque se reconoce la importancia del protocolo
sub,acente- no se crear un estereotipo de protocolo$
;';
eeconectorff
nombconec
eeconectorff nombreConec
Figura <$B$ 5conos de conector$
Dos conectores pueden concatenarse si uno de ellos tiene un enlace compatible
con uno del otro conector$ (sta situacin se analia en la siguiente seccin$
(.(.). 1eglas e constr"ccin
La generaliacin debe darse entre elementos del mismo estereotipo- para todos
los elementos agregados$
4sociaciones# adems de las asociaciones estndar de 3ML- se permiten#
a/ contencin entre Componente , !uerto- entre !uerto , Lnea- entre
Conector , (nlace- (ntre (nlace , LneaI
b/ asociacin que representa cone0in entre dos componentes indicada
con la clase de asociacin Conector$ Cuando e0iste un solo puerto en cada
Componente- se puede indicar directamente como una lnea entre ambosI
cuando *a, otros puertos- la lnea se traa entre los puertos que conecta$
!ara considerarse correctamente construido un modelo empleando los elementos
descritos- se debe cumplir que#
a/ cada componente tipo debe contener al menos un puerto , reglas que inclu,an
la funcionalidad que ofreceI
b/ cada componente instancia debe incluir reglas especficas de la funcionalidad
que presenta- la cual debe ser compatible con la del tipoI
c/ cada conector tipo debe incluir al menos un enlace , la descripcin de su
interaccin tpicaI opcionalmente puede incluir formas adicionales de
interaccin formando escenarios o bien una descripcin que inclu,a todas las
partes opcionalesI
d/ cada conector instancia debe aparecer ligado a dos puertos en dos
componentes instancia distintos , sus papeles , lneas deben ser compatiblesI
(.(.4. Comentarios
!ara los componentes es importante la descripcin de sus funciones .en +ista
e0terna o de ca1a negra/ dada como una coleccin de pre , postcondiciones que
relacionan lneas de entrada de sus puertos con lneas de salida , algunas de sus
;'&
propiedades$ !ara ma,or claridad se pueden e0presar como pare1as
.precondicin- postcondicin/ equi+alentes a una regla de situacin6accin$
(l conector que liga dos componentes corresponde a cualquier tipo de interaccin
entre estos- pero son muc*o ms que las cone0iones entre clases o entre
componentes en el sentido de 3ML$ (ntre las interacciones se inclu,en# crear o
in+ocar un componente .instancia/- solicitar alg)n ser+icio a un componente cu,a
referencia se recibi como parmetro o que est ligado por agregacin o
delegacin$
3n conector siempre conecta dos puertos con relacin de complementariedad$
(sta relacin e0iste si
a/ los puertos tienen naturalea opuesta
b/ tienen el mismo n)mero de lneas , 2stas- tomadas por pare1as- tienen
el mismo tipo de datos- pero con direccin contraria$
Si se aceptan algunas lneas opcionales- se podra rela1ar la complementariedad a
compatibilidad$
La interaccin tpica asociada con un conector , +arios componentes puede +erse
como un protocolo- que se e0presa por medio de diagrama de secuencia- de
acti+idades o de estados$
(.(.5 *lementos aicionales !"e se moifican.
4 partir de los elementos bsicos que se agregan a 3ML- se agregan o modifican
una serie de elementos deri+ados que son necesarios para la descripcin de una
aplicacin basada en componentes , que sir+a para deri+ar pruebas$ Tales
elementos son#
a/ Diagrama topolgico# este es un diagrama que relaciona los
componentes , conectores que forman una aplicacin- inclu,endo sus
di+ersas interacciones$ Debe distinguirse del uso del t2rmino KtopolgicoL en
3ML- donde se refiere ms bien al despliegue$
b/ Diagrama de despliegue# no se modifica- pero se precisan algunos
elementos$
c/ Casos de uso# no se modifican- pero se precisa su contenido en el
conte0to de 'ruipp$
d/ Diagramas de secuencia# se les agregan elementos menores para
adecuarlos a componentes$
(stos elementos se discuten en las secciones siguientes$
;'<
:*<* Us" de e)e#ent"s de Ar3ui!!
(n esta seccin se ampla la descripcin de los elementos agregados o
modificados$ Se inclu,e notacin de ob1etos , en forma te0tual- que se podr
emplear en *erramientas que usen Ar!"ipp$
(.).1 Moelao e tipos e instancias e componentes
3n componente se puede denotar grficamente como una clase con estereotipo ,
los puertos agregados en su frontera- como se indic en la seccin anterior .+er
Figura <$</$
!ara la descripcin completa de un componente se utilia#
a/ descripcin de sus puertos , de las lneas que 2stos inclu,en-
b/ descripcin de su funcionalidad# como no interesa la implementacin- se
puede utiliar una combinacin de precondiciones , postcondiciones
asociadas con las diferentes lneas de sus puertos- agrupadas en forma de
reglas que se incluirn en los diagramas anteriores
c/ diagrama de estados cuando el componente lo requieraI este se realia con
las *erramientas estndar de 3ML$
(n el modelado de tipos se recomienda mantenerlos simples- indicando solamente
aquellos elementos necesarios en la interaccin con otros componentes$
3n componente puede deri+ar sus caractersticas de tipos anteriores- ,a sea de
uno o ms$ Dado que Ar!"ipp cumple con 3ML- la *erencia es fcil de indicar$
Debe tenerse cuidado con los puertos del mismo tipo que pro+engan de diferentes
tipos de componentes de quienes se *ereda$ (n algunos casos *abrn de
mantenerse a)n cuando parecan duplicados , en otras ocasiones se podrn
reunir en un solo puerto$
Los componentes pueden describirse detalladamente como ob1etos- como en la
Figura <$> , tambi2n en forma de te0to- misma que se puede usar para alimentar
*erramientas$
La forma te0tual ser#
. componente enombre6compof edesc6compof /
edesc6compof ##Q e+acof ] ? . epuertof ] e*eredaf ] e+al6etiqf ]
ereglaf /Ag
e+al6etiqf ##Q . epropiedadf e+alorf /
epropiedadf ##Q seleccin ] adaptacin ] arc*Hadapta
e*eredaf ##Q . *ereda enombref /
enombre6compof ##Q enombref
epropiedadf##Q seleccin ] adaptacion ] arc*6adapta
;'B
Diagra#a est,tic"
Los tipos de componente pueden formar una 1erarqua- donde se apro+ec*e la
*erencia para no tener que definir a pi2 cada tipo$ !or otro lado- las instancias de
componentes deben guardar relacin con el tipo del que pro+ienen$ Todo 2sto se
puede e0presar en un diagrama esttico- seme1ante a un diagrama de clases en
orientacin a ob1etos$
6
eecomponenteff
nombreComponente
;$$g
eereglaff
regla(specfica
eepuertoff
nombre!uerto
naturalea
eelneaff
nombreLinea
papel
tipo
;$$g
;
6
'$$g
Figura <$> Componente con sus partes
(.).2 Moelao e p"ertos
Los puertos formarn parte de componentes , enlaces- por lo cual rara +e se
mane1arn por separado$ (n la Figura <$D se muestra un puerto con sus partes
.lneas/$
(n el modelado de los puertos- ba1o la plataforma Ja+a &- es com)n que
aparecan in+ocaciones a cualquier m2todo de la interfa propia del componente-
como es el caso de los call6bac7 en ob1etos remotos$ !ara fines del modelado se
inclu,e una sola lnea que permite la seleccin de cualquiera de tales m2todos$
(l formato de te0to para los puertos es como sigue#
. puerto enombre6ptof edesc6ptof /
e desc6ptof ##Q e+acof ] ? . e+al6etiqf ] elneaf / Ag
;'>
enombre6ptof ##Q enombref ] Wenombref
epropiedadf##Q naturalea
eepuertoff
nombre!uerto
naturalea
eelneaff
nombreLinea
papel
tipo
;$$g
;
Figura <$D !uerto con sus partes
(.).(. $nea
Las lneas- a pesar de su importancia- rara +e aparecern grficamente- ,a que
su uso +ol+era ilegibles los diagramas$ 3sualmente ir incluida dentro de un
puerto$ La lnea es un elemento terminal- simple- que no est formado por otras
partes- pero tiene algunos +alores etiquetados importantes- como se +e en la
Figura <$E$
eelneaff
nombreLinea
papel
tipo
Figura <$E$ Lnea
Su representacin en forma de te0to- que puede indicarse por separado o dentro
de la descripcin del puerto- es la siguiente#
. linea enombre6linf edesc6lineaf /
edesc6lineaf ##Q e+acof ] ? . e+al6etiqf / Ag
enombre6linf ##Q enombref
epropiedadf ##Q papel ] tipo
;'D
(.).) Moelao e conectores
3n conector tiene como representacin grfica la que corresponde a una clase de
asociacin#
!ara describir completamente un conector se utiliarn#
a/ descripcin de los puertos , lneas que forman cada conector
b/ descripcin de la interaccin por medio de diagramas de secuencia o de
colaboracin$
c/ descripcin de su funcionalidad- si es rele+ante- en forma similar a los
componentes
!ara los conectores se siguen los mismos principios de los componentes- pero en
general no *abr tantas instancias diferentesI ms bien los conectores especficos
se ad*ieren a conectores tpicos con pocas implementaciones diferentes$ 4s
pues- debe ser ms cuidadosa la modelacin de tipos de conectores- indicando
toda la informacin disponible$ (n la Figura <$= se muestra un e1emplo de
conector$
;$$g
eeestereotipoff
Conector
Localidad
eeestereotipoff
(nlace
categoraQcomunicacin
eeestereotipoff
(nlace
categoraQcontrol
'$$;
eesecuenciaff
secu
;$$g
Figura <$= Modelado de un conector
Interacci"nes as"ciadas c"n un c"nect"r
La parte importante del conector es la descripcin de su comportamiento- es decir
la interaccin entre componentes que representa- la cual es- semnticamente-
mu, similar al concepto de colaboracin en 3ML- por lo que se describe usando
sus di+ersas posibilidades$ !ara *acerlo pueden usarse# diagramas de estados-
diagramas de acti+idades- diagramas de secuencia , diagramas de colaboracin$
(n muc*os casos los ms adecuados sern los diagramas de secuencia$ Ms
adelante se describe la manera en que se utiliarn en 'ruipp$
;'E
C"ncatenacin de c"nect"res*
3n aspecto importante de los conectores es que pueden enlaarse entre s- de
modo que e0istan dos o ms de ellos entre dos componentes$ Tal es el caso de la
cone0in entre un web browser , un ser+let o entre una aplicacin de cualquier
tipo , una base de datos +a 1dbc- odbc , dri+ers especficos$ (n estos casos- los
conectores se empatan de manera que los papeles sean compatibles$ Los enlaces
conectados se pueden +er como enlaces resultantes donde los papeles que se
*an ligado desaparecen , las reglas de accin se combinanI los enlaces que no
tienen compa"ero en alguno de los conectores no se utilian- a menos que tengan
efecto )nicamente sobre un componente$
(n cierto sentido el conector resultante puede +erse como la composicin de un
conector seguido del otro en sentido matemtico$
eecomponenteff
4
eecomponenteff
4
eeconectorff
U
eeconectorff
L
eecomponenteff
4
eecomponenteff
4
eeconectorff
UL
Dos conectores originales
Conector resultante
Figura <$: Concatenacin de conectores
Las interacciones correspondientes a ambos conectores se pueden ligar- como se
ilustra en la Figura <$;'- que muestra la composicin de las interacciones para
algunas lneas$
;'=
Lnea a Lneal d Lnea c Lnea b
5nteraccin ; 5nteraccin &
Conector U Conector L
Lnea a Lneal d
5nteraccin <
Conector UL
Figura <$;'$ Combinacin de interacciones en conector concatenado$
La representacin de un conector en forma de te0to es como sigue#
. conector enombre6conecf edesc6conectf /
edesc6conectf ##Q . e+al6etiqf ? econcatf ] eenlacesf esecuenciasfA /
econcatf ##Q .concatena .enombre6conecf enombre6conecf /
enombre6conecf ##Q enombref
e+al6etiqf ##Q .localidad equelocf /
equelocf ##Q local ] equipo ] red
eenlacesf ##Q eenlacef ? eenlacef Ag
esecuenciasf ##Q esecuenciaf ? esecuenciaf Ag
La )ltima forma de descripcin corresponde a la concatenacin de conectores
pre+iamente definidos en uno solo$
(.).4 Moelao e enlaces
Los enlaces no aparecern +isiblemente- pero forman parte de la estructura de los
conectores$ Su representacin como ob1eto se muestra en la Figura <$;;- en sus
dos formas# la que comunica dos componentes , la que enlaa componente con el
conector- con propsitos de control$
;':
eeestereotipoff
Lnea
eeestereotipoff
!uerto
naturalea
eeestereotipoff
Lnea
;$$g
;
;$$g
; ;
eeestereotipoff
!uerto
naturalea
;$$g
;
;$$g (n caso de ser ms
de uno- deben ser
instancias
del mismo tipo
eeestereotipoff
(nlace
CategoraQcomunicacin
Figura <$;;a (structuras de (nlace$
eeestereotipoff
(nlace
categoraQcontrol
eeestereotipoff
Lnea
eeestereotipoff
!uerto
naturalea
;
;$$g
Figura <$;;b (structuras de (nlace
;;'
(n forma de te0to se puede describir as#
eenlacef##Q .enlace enomb6enlaf . edescr6enlaf / /
enomb6enlaf##Q enombref
edescr6enlaf##Q elneaf ] e+al6etiqf
e+al6etiqf##Q categora Q ? control ] comunicacin A
(.).5. &iagrama topolgico
3n diagrama topolgico muestra las di+ersas interacciones entre componentes ,
los conectadores asociados con ellas para una aplicacin dada$ 3n diagrama
topolgico no puede incluir componentes desconectadas ni conectores ligados por
uno solo de sus e0tremos- ,a que ambos casos no tendran sentido en una
aplicacin$
Grficamente- un diagrama topolgico se presenta como en la Figura <$;&#
eecomponenteff
login
eecomponenteff
cla+es
eecomponenteff
prepara
eeconectorff
Jdbc6odbc
eeconectorff
stream
Figura <$;& Diagrama topolgico
eecomponenteff
login
eecomponenteff
cla+es
eeconectorff
Jdbc6odbc
;$$n ;
Figura <$;< Segmento de diagrama topolgico indicando multiplicidad$
;;;
(sta corresponde a un diagrama donde aparecen los componentes- puertos ,
conectores que participan$ Cuando e0iste multiplicidad en alguno de los
elementos- se puede indicar como en la Figura <$;<#
3n diagrama topolgico puede describirse como ob1eto de la manera que se
muestra en la Figura <$;B$
La forma de te0to para un diagrama topolgico es como sigue#
. topologia enombre6dtopf econe0ionesf /
econe0ionesf ##Q ? econe0inf Ag
econe0inf ##Q . enombre conectorf .enombre componentef enombre
puertof / . enombre componentef enombre puertof / /
enombre6dtopf ##Q enombref
eediagramaf
topologico
cone0in
eeconectorff eecomponenteff
puerto
& ;
g g
;
;$$g
diferentes
Figura <$;B Diagrama topolgico , sus partes
(.).:. Caso e "so
3n caso de uso en 'ruipp consiste de
a/ descripcin te0tual para documentacin
b/ con1unto de interacciones
c/ .opcional/ diagrama de acti+idades donde los nodos representan
interacciones- )til cuando *a,a que describir orden entre interacciones$
d/ !ropiedades para perfil#
!osibleHuso# +alor que indica que tan posible es la ocurrencia del caso de
usoI toma +alores en Ysiempre- ma,ora- alguno- raro- nuncaZI nunca se
agrega por simetra- pero no se usa- ,a que indicara un caso de uso que
nunca se presentar$ (l +alor de omisin es siempre$ 4l generar pruebas-
;;&
se preferirn los casos que indiquen alta posibilidad de uso , sern
obligatorias las de los casos de uso con +alor siempre$
FrecuenciaHuso# indica la frecuencia de ocurrencia de un caso de uso en
relacin con una sesin de traba1o- dado que efecti+amente ocurra$ Sus
+alores se miden como un porcenta1e de una sesin$ Su uso ser como
gua , no es necesaria ma,or precisin que aquella que el desarrollador
quiera darleI se supondr que a ma,or +alor- ms importante es su prueba$
!ara representar grficamente un caso de uso se utilia la misma notacin de
3ML$
!ara describir un caso de uso en una *erramienta- se utilia en forma de ob1eto-
como se muestra en la Figura <$;>#
Descripcin
te0tual
Caso de uso
posibleHuso
frecuenciaHuso
eediagramaff
secuencia
eediagramaff
acti+idades
; '$$; ;$$g
Figura <$;> Caso de uso , sus partes
La representacin de un caso de uso en forma de te0to es como sigue#
. casoHuso enombre6casof edesc6casof /
edesc6casof ##Q . ete0tof esecuenciasf ?eacti+idadesfA /
eacti+idadesf ##Q .ordenHint enombref erel de ordenf /
erel de ordenf ##Q einiciof ? . eprecedef ] ebifurcaf / Ag
eprecedef ##Q .precede enombHintf enombHintf /
ebifurcaf ##Q .si econdicinf enombref enombHintf enombHintf /
einiciof ##Q .inicio enombref /
enombHintf ##Q F5@ ] enombref
enombre6casof ##Q enombref
(.).; <nteraccin
3na interaccin representa una forma especfica en que interact)an dos o ms
componentes +a uno o ms conectores$ (n 'ruipp se presentan en dos
ocasiones importantes# en la descripcin de un conector- donde muestra la
relacin entre los puertos que lo forman , en la descripcin de casos de uso$
;;<
Los diagramas de secuencia , los de colaboracin de 3ML descansan sobre el
concepto de colaboracin- la cual inclu,e un grupo de clasificadores que
interact)an .puede ser cualquiera- incluso subsistemas/- que pueden ser
clasificadores especficos o papeles .roles/ gen2ricos- , un con1unto de
interacciones entre los clasificadores$ Las interacciones se forman de con1untos de
mensa1es con informacin acerca del orden parcial que guardan entre s$
4unque las *erramientas no consideran todas las +ariantes aceptadas por 3ML-
para la descripcin de conectores con+iene considerar los mensa1es con la
etiqueta completa que marca 3ML- ,a que esta contiene la informacin del orden
entre mensa1es$
(n 3ML ?3ML- ;:::A- una etiqueta de mensa1e se forma como sigue#
predecesores secuencia6de6condiciones +alor6de6retorno #Q
nombre6de6mensa1e parmetros
H predecesores es una lista de n)meros de mensa1e separados por coma ,
terminada en diagonal .KVL/$
H secuencia6de6condiciones es una lista de t2rminos6de6secuencia separados
por punto , terminada en dos puntos .K#L/$
H t2rmino de secuencia representa un ni+el de anidamiento , se forma como#
?integer ] nombreA ?recurrenciaA
H el entero representa un n)mero de orden secuencial dentro del ni+el de
anidamientoI el nombre se usa cuando *a, +arios elementos concurrentes$
H recurrencia indica si *a, repeticiones- condiciones o concurrencia# g
?clusula de iteracinA para iteracin- ?clusula condicionalA para
condiciones , gVV para concurrencia$ Las clusulas se escriben seg)n
con+enga l dise"ador$
Las interacciones en 3ML pueden describir casos especficos o generales- *asta
el caso e0tremo de representar todas las posibles interacciones$ (n el caso de
'ruipp con+iene que los conectores sean descritos usando formas ms o menos
generales- a menos que sea mu, complicado$ (n cambio- las interacciones que se
presentan en una aplicacin dada- con+endr ms describirlas en t2rminos de
casos de uso especficos$
!or a*ora las interacciones se limitarn al formato de diagrama de secuencia de
3ML- con las con+enciones siguientes#
a/ cuando corresponda a una interaccin de un conector tipo- los
clasificadores que participan sern lneas que forman parte de los puertos
que corresponden al conector
b/ cuando se trate de una interaccin entre componentes- los clasificadores
sern lneas identificadas por componente- puerto , lnea- separadas por
puntoI cuando sea claro- se puede omitir el puerto , a)n la lnea
;;B
Se usar la notacin completa para identificar las interacciones indi+iduales que
autoria 3ML- de modo que se cuente con repeticin- bifurcaciones , regresos$
La representacin grfica ser seme1ante a la de 3ML- con las precisiones
siguientes#
a/ cuando se describan interacciones tpicas de un conector- slo se indicarn
puerto , lneaI el puerto podr representarse como una particin del
diagrama de1ando un puerto a la derec*a , otro a la iquierda , nombrando
e0plcitamente las lneas$
b/ Cuando se trate de interacciones incluidas en casos de uso- se usar el
nombre de la componente- seguido del nombre del puerto , de la lnea-
separados por puntos$ Cuando *a,a un solo puerto se podr omitir su
nombre$ Grficamente se puede representar como en la figura <$;D- para
e+itar el e0ceso de clasificadores
Componente?$puertoA
lnea lnea lnea
Figura <$;D Clasificador para interacciones entre lneas
La representacin como ob1eto de un diagrama de secuencia ser como se
muestra en la Figura <$;E#
eediagramaff
secuencia
;$$g
parmetro
orden
'$$g
'$$;
5nteraccinHind
identificador
retorno
mensa1e
Figura <$;E Diagrama de secuencia con sus partes
La descripcin de un diagrama de secuencia en forma de te0to ser como sigue#
esecuenciaf ##Q . secuencia enomb6secf . edescr6secf / /
edescr6secf ##Q einteraccinHindf ? einteraccinHindf Ag
einteraccinHindf ##Q .interaccin eidentificador .edescrHinterf / /f
eidentificadorf ##Q en)merof ?$en)merof Ag
edescrHinterf ##Q ?eordenfA emensa1ef ? eretornof A ? eparmetrosf A
;;>
eordenf ##Q ?edependenciaf A ?erepeticinf ] econdicinfA
edependenciaf ##Q eidentificadorf ?- eidentificadorf Ag
erepeticinf ##Q g ? M?M enombreH+ariablef Q elmHinff ?$$ elmHsupf A MAN A
econdicinf ##Q M?M ee0presin booleanaf MAN
emensa1ef ##Q enombre de mensa1ef
eretornof ##Q etipo de datof
eparmetrosf ##Q . eparmetrof ?- eparmetrof Ag /
eparmetrof ##Q e+alorf ] enombre de +ariablef
enomb6secf ##Q enombref
(.).= &iagrama e esplieg"e
(ste diagrama tambi2n es secundario- pero de utilidad para la planeacin del
orden de las pruebas- dentro de la estrategia propuesta- ,a que *ace referencia a
los nodos especficos donde residirn las di+ersas componentes , con ello los
elementos especficos de software intermedio , otros au0iliares$ (n el caso de la
plataforma Ja+a & sern de especial importancia los contenedores , ser+idores
alo1ados en cada nodo , que atendern a las componentes a desplegar en ellos$
(n la Figura <$;= se muestra un e1emplo de este diagrama$
(n los equipos incluidos en un diagrama de despliegue con+iene incluir#
a/ indicar si es un equipo especfico o gen2rico
b/ la plataforma
c/ cardinalidad
d/ si es gen2rico- el con1unto posible o tpico de plataformas
La descripcin te0tual de este diagrama es como sigue#
ediag desplieguef ##Q . despliegue enombreHdesplf .edescrHdesplf / /
edescrHdesplf ##Q eequipof ] econe0inf
eequipof ##Q .equipo enombreHeqf .edescrHeqf / /
edescrHeqf ##Q ecomponentef ] e+alHetiqf ] ecardinalidadf
e+alHetiqf ##Q plataformaH*ard Q ?enombref ] gen2ricof A
e+alHetiqf ##Q plataformaHsoft Q ?enombref ] gen2ricof A
ecardinalidadf ##Q cardinalidad Q en)merof
enombreHeqf ##Q enombref
enombreHdesplf ##Q enombref
;;D
eediagramaff
despliegue
(quipo
cardinalidad
plataformaH*ard
plataformaHsoft
cone0in
componente
;$$g
;$$g ;$$g
Figura <$;= Diagrama de despliegue$
(.).1> &escripcin e aplicaciones con Ar!"ipp
!ara describir un subsistema o sistema completo basado en componentes- se
utilian al menos#
a$ descripcin de componentes , conectores empleados
b$ diagrama topolgico
c$ casos de uso relati+os a los componentes- que inclu,an los
diagramas de interaccin correspondientes a sus escenarios
d$ diagrama de despliegue
3na aplicacin inclu,e el te0to siguiente#
eaplicacinf ##Q .aplicacin enombreHaplf . edescriHaplf / /
edescrHaplf ##Q ? ecomponentefAg ?econectorfAg ?ecaso de usof Ag
?ediagHacti+fA ediagHtopologicof ediag desplieguef
:*A C"#!"nentes en )a !)ata$"r#a >a&a 5
La plataforma Ja+a &- elegida para 2ste traba1o- inclu,e +arios elementos de
inter2s- ,a sea por su papel de componente o como conectores entre ellos$ (n
esta seccin se discute qu2 elementos se pueden considerar componentes ,
luego se presentan e1emplos de modelado de componentes , conectores usando
'ruipp$
;;E
(.4.1 *lementos a consierar
La plataforma Ja+a & inclu,e di+ersos elementos que pueden considerarse
componentes- inclu,endo las que sus autores consideran tales , las que sin serlo
se comportan de modo similar$ (n la Tabla <$; se presentan algunos elementos
candidatos a componentes- mismos que se discuten a continuacin$
a/ -ava.eans$ (stos son elementos que por su naturalea +ienen
encapsulados , con facilidades para descubrir sus interfaces
interacti+amente$ Su ensamble se realia por medio de *erramientas que
pueden ser +isuales$ Se conectan por di+ersos medios- especialmente por
e+entos$ Se emplean muc*o en construccin de interfaces , de applets$
b/ E-. de todos tipos$ (stos son componentes por definicin$ 8ienen
preparados para integrarse dinmicamente en aplicaciones$ (mplean
contenedores para asegurar su funcionamiento$ (0isten dos grandes
categoras# E-. de sesin- orientados a proceso- , E-. de entidad-
orientados a representar datos$ Los primeros pueden o no tener estado$
c/ 'pplets, servlets, -/&# Las applets se emplean como elementos
inmersos en pginas JTMLI cada +e que son in+ocados deben crearse$
Los servlets son seme1antes pero se reutilian de un banco de servlets
disponibles- por lo cual son ms econmicos- llamados a +eces Kclientes
delgadosLI operan ba1o el principio de una sola funcin que inclu,e leer
parmetros- realiar la funcin , en+iar respuesta en formato JTML$ Las
-/& son scripts que generan pginas en JTML al ser in+ocadasI aunque se
implementan como servlets- tienen limitaciones de intercone0in con otros
tipos de componentes$ Los ser+lets requieren un contenedor llamado
/ervlet Engine$ Los applets usan los browsers como contenedores$
d/ Fb1etos distribuidos .+a 9M5 o 55F!/# ob1etos que pueden descubrirse ,
emplearse a tra+2s de un ser+icio de nombres ante el que estn
registrados$ (l mecanismo 9M5 es tpico de Sun- mientras que 55F! es un
m2todo empleado por CF9%4 , a*ora soportado por Ja+a$
e/ Datos .+a streams/# estos elementos- aunque relati+amente pasi+os- son
usados en todas las formas de programacin$ 4unque su estructura es
simple- puede suponerse que representan la salida de un proceso con un
solo m2todo que permite pedirle datos$
f/ Ser+idores e0ternos .accesibles por di+ersas +as como soc7ets/# esto
inclu,e ser+idores de correos- aplicaciones legadas , otros elementos que
se comunican usualmente +a soc7ets u otro mecanismo similar a streams$
g/ Clientes tipo browser# estos son elementos independientes- capaces de
comunicarse con otras componentes +a 5nternet$ 3sualmente acti+an plugins
.applets o similares/ o acti+an ser+lets , JS!s$
;;=
Tabla <$; Caractersticas satisfec*as por cada elemento considerado$
Ja+a
%eans-
applets
Ser+lets-
JS!
(J% Fb1etos
distri
buidos
.9M5-
55F!/
Datos
+a
streams
Ser+i
dores
e0ternos
+a
soc7ets
Clientes
e0ter
nos
.brow
ser/
(ncapsu
lado
.;/ .&/
Desplie
gue
indi+idual

4cceso
slo por
interfaces
.</ .</ .</ .</
5somor
fismo
concepto
negocios
.B/ .B/
Contene
dorVcon
te0to
.>/ .>/ .>/ .D/ .E/ .E/ .>/
!ara
compo
nerse

Descubrir
interfa al
e1ecutar

Frienta
cin
empresa
.=/ .=/ .=/
@otas#
.;/ @o es indispensable- ,a que son parte de un ser+idor de una empresa
particular$
.&/ Dada la consideracin de que son resultado de alg)n proceso no +isible
., ausente/- se puede decir que Kno se tiene acceso al cdigoL$
.</ 4 tra+2s de un protocolo bien establecido$
.B/ !uede serlo
.>/ (0plcitamente
.D/ Como ser+icios especiales- como el de nombres$
.E/ Slo si se considera el sistema operati+o como conte0to base$
.=/ @o especialmente- pero no lo e0clu,e$
;;:
!uede +erse que los elementos cumplen con la ma,ora de las caractersticas-
qui rela1ndolas un poco$ 4lgunas de las que no satisfacen pueden aceptarse de
momento- mientras no se desarrolla ms el mercado de componentes$
3n comentario especial acerca de ob1etos distribuidos# 2stos representan
elementos de ba1a granularidad , que tal +e lleguen a ser eliminados por
componentes maduras$ Sin embargo- por a*ora son importantes especialmente
para interaccin dentro de un mismo ni+el .tier/- ,a que los contenedores de (J%
imponen una gran sobrecarga muc*as +eces in1ustificada$ De *ec*o a +eces se
recomienda considerar el no emplear +arios (J% en el mismo ni+el- para *acer
ms eficiente su comunicacin$ Tanto los ob1etos distribuidos como los (J% puede
compartir ser+icio de nombres , forma de comunicacin$
(.4.2 1epresentacin e elementos e .ava 2 con Ar!"ipp
(n esta subseccin se presentan modelos de algunos elementos discutidos en la
anterior$ (l modelado no es definiti+o- sino que se proponen formas bsicas de los
elementos principales que importan para la generacin de pruebas , son ms una
gua que un catlogo de modelos terminados$ (l ap2ndice 4 ampla la lista$
Como se realian los modelos con 'ruipp , con los supuestos acerca de
conectores , componentes discutidos en las primeras secciones- los modelos no
resultan iguales a los mostrados en la documentacin propia de tales elementos ni
a los modelos propuestos por otros autores- empleando otras notaciones ,
supuestos$
:*A*5*4 C"#!"nentes
Jasta el momento se *an analiado los tipos de componente que se muestran en
la Tabla <$& , que se describen a continuacin$ !odr notarse que no todos tienen
el mismo ni+el de detalle- aspecto que se corregir conforme se a+ance en el
traba1o$
Tabla <$&$ Tipos de componente
!ropios de Ja+a
Ja+a%ean
4pplet
Ser+let
Fb1eto remoto
(nterprise Ja+a%ean
4dicionales
4rc*i+o simple
Ceb browser
%ase de datos
Ser+idor e0terno
;&'
De 2stos se presentan el modelo de un 4pplet , el de un Ja+a%ean$
A!!)ets*
3n 4pplet es una peque"a aplicacin que se e1ecuta dentro de un browser- pero
que es un elemento escrito en Ja+a$ Muc*os 4pplets estn escritos como
Ja+a%eans o grupos de ellos$ Su comunicacin bsica es con un browser , por
ello su estructura necesaria es como se muestra en la Figura <$;:$
eecomponenteff
4pplet
eepuertoff
cons6applett
eelneaff
Solicitud
eelneaff
9espuesta
Figura <$;:$ (structura de un 4pplet$
>a&a+eans*
Los Ja+a%eans pueden incluir muc*os elementos de la plataforma Ja+a &- pero
*a, dos que son mu, importantes# la capacidad de introspeccin , la de
comunicacin empleando e+entos$ 4s pues- en el modelo de la Figura <$&' se
ilustran los puertos correspondientes a tales aspectos$ Ftros %eans que resulten
ms comple1os pueden remodelarse o *eredar de este modelo sus caractersticas
, agregar otras$
;&;
eecomponenteff
Ja+a%ean
eepuertoff
p5ntrospeccin
eelneaff
!regunta
eepuertoff
p(+ento
eelneaff
9eg
eelneaff
Desreg
eelneaff
Ja,e+ento
eelneaff
Funcin
Figura <$&'$ Modelado de aspectos bsicos de Ja+a%eans
:*A*5*5 C"nect"res
(n esta seccin se describen los conectores de tipo incluido en la Tabla <$<- en la
cual se indican- adems- los tipos de componente o conector a los que conecta$
!ara cada tipo se presenta su descripcin , su modelado con el LD4 propuesto$
Tabla <$<$ Tipos de conector
Ti!" de c"nect"r Ti!" de c"#!"nente
base9 c"ntened"ra "
acti&a
Ti!" de c"nect"r9
c"#!"nente au8i)iar9
c"ntenida " !asi&a
(+entos Ja+a%ean Ja+a%ean
Jttp Ceb browser 4pplet- conHser+let
ConHser+let Jttp Ser+let
9mi 4plicacin- applet Fb1eto remoto
Stream 4plicacin- applet- 4rc*i+o simple
Soc7et 4plicacin Ser+idor e0terno
Jdbc 4plicacin %ase de datos
ConHe1b (1b
4 continuacin se presenta el conector de e+entos para Ja+a%eans$ (n el
ap2ndice 4 se muestran otros conectores de 2sta plataforma$
E&ent"s
3n elemento importante en la comunicacin entre componentes concurrentes del
tipo Ja+a%eans es el conector de e+entos- que en+a a+iso de la ocurrencia de un
e+ento en un componente origen a uno o ms destinos$ (l e+ento contiene
informacin del emisor , puede lle+ar otros datos$ 4l recibir un e+ento- un
componente puede solicitar otros ser+icios del emisor a tra+2s de su identificacin
recibida$ !ara que funcione el conector- cada componente destino debe ligarse-
;&&
por s o a tra+2s de un tercero- con el emisorI tambi2n puede desligarse en forma
similar$ (n la Figura <$&; se muestran los principales elementos de 2ste tipo de
conector$
eeconectorff
(+ento
eeenlaceff
consulta
eelneaff
5nicia
eelnealff
9ecibe
eeenlaceff
a+iso
eelnealff
5nicia
eelneaff
9ecibe
eeenlaceff
desregistro
eelnealff
!ide
eelneaff
4cepta
eeenlaceff
9egistro
eelneaff
!ide
eelneaff
4cepta
Figura <$&;$ Modelado del conector (+ento
La cone0in de componentes +a e+entos se puede representar como en la Figura
<$&& cuando *a, una sola fuente , un solo destinoI si *ubiese +arios
componentes ligados a la misma fuente de e+entos se representa como en la
Figura <$&<I si *ubiera +arias fuentes de e+ento ligadas al mismo componente
destino se usara una configuracin similar- pero con orgenes diferentes$
3n mismo componente puede tener +arios puertos para comunicacin por
e+entos- pero esta situacin no se ilustra aqu$
eecomponenteff
%ean;
eecomponenteff
%ean&
eeconectorff
(+ento
Figura <$&&$ Cone0in de Ja+a%eans usando (+ento$
;&<
Debe notarse que la implementacin particular de e+entos en Ja+a & re)ne todas
las llamadas en una sola estructura de datos , los a+isos se en+an a todos los
elementos registrados- como un solo conector- pero su representacin de tal modo
resulta ms comple1a de lo necesario para los fines de este traba1o- por lo cual se
prefiri de1ar cada enlace grficamente separado$
La interaccin representada por el conector (+ento se puede representar
mediante un diagrama de estados- como se muestra en la Figura <$&<$ (n 2sta se
indican los cambios de estado por medio de una condicin sobre papeles- como
Kconsulta$5nicioL que puede estar acti+a- , una accin o postcondicin como
Kacti+ar consulta$9ecibeL$ otra forma es la mostrada en la Figura <$&B- que emplea
un diagrama de secuencia$
inacti+o
registro$!ide acti+a
V acti+ar registro$4cepta
desregistro$!ide acti+a
V acti+ar desregistro$4cepta
a+iso$5nicia acti+o
V acti+ar a+iso$9ecibe
consulta$5nicio acti+a
V acti+ar consulta$9ecibe
*a, enlaces
Figura <$&<$ Diagrama de estados de la interaccin de (+ento
;&B
#fuente #destino
;#registra
;V&#a+isa
&V< g?'$$nA# a+isa
&VB g?'$$nA consulta
&-<-BV># desregistra
Figura <$&B$ Diagrama de secuencia para conector de e+entos$
:*B A!)icacin de e6e#!)"
Con el fin de e1emplificar el uso de 'ruipp en el modelado de una aplicacin
completa- se presentarn todos los pasos de este proceso para una aplicacin
mu, sencilla$
(.5.1. $a aplicacin &amecalif
Se desea un sistema de consulta de calificaciones en lnea- +a 5nternet- donde el
maestro mantiene una base de datos con dos tipos de datos# nombres , cla+es de
sus alumnos , calificaciones de los alumnos$
Slo *a, dos funciones para el maestro# actualiar la lista de alumnos , actualiar
las calificaciones$
Los alumnos tienen una funcin# identificarse , solicitar su calificacin$(sta
aplicacin puede modificarse fcilmente a consulta de cualquier tipoI inclu,endo
uno o dos parmetros ms se puede consultar sobre una lista de productos o
sobre estado de cuentas$
La aplicacin se distingue de otras similares- pero ms comple1as- en que no
forma una sesin$
4unque es un detalle de implementacin- se supondr que la base de datos reside
en una *o1a de clculo , que el maestro emplea una aplicacin como (0cel para
su actualiacin$
Solamente se modelar la parte del alumno- que es la interesante- ,a que la parte
del maestro se puede realiar fuera de lnea con aplicaciones con+encionales$
;&>
(.5.2. Casos e "so
(n este caso se considera un solo caso de uso- aunque 2ste contendr +arios
escenarios$ (l caso de uso se muestra en la Figura <$&> , se describe a
continuacin$
alumno
Consulta
Figura <$&> Caso de uso de la aplicacin Damecalif
< B Cuartil
E$= : Calificacin
!ro,ecto Tareas Concepto
Figura <$&D Salida esperada a una consulta
Damecalif
(0iste un problema con su identificacin$
!or fa+or re+sela , +uel+a a intentarlo$
Figura <$&E Salida en caso de error en nombre o contrase"a
3n alumno in+oca la pgina ligada a la aplicacin , se identifica .nombre ,
contrase"a/$ Si est registrado , su contrase"a es correcta- recibe una pgina
donde se muestran sus calificaciones en forma de tabla- seme1antes a la de la
Figura <$&D$ Si no est registrado o no es correcta su contrase"a- recibe una
pgina de error- como la que se muestra en la Figura <$&E$
(.5.(. Ar!"itect"ra prop"esta
;&D
!ara esta aplicacin se propone emplear un ser+let como interfa de usuario- un
ob1eto remoto que controlar el acceso a la base de datos , una base de datos
que estar representada en una *o1a de clculo$ La comunicacin entre el ser+let
, el ob1eto remoto se realiar +a 9M5 , el acceso a base de datos +a 1dbc6odbc$
La arquitectura propuesta corresponde al diagrama topolgico que se presenta en
la Figura <$&=$
Ceb
browser
.gen2rico/
*ttp6ser+let
eeser+letff
consulta
9M5
eeob1 remotoff
4ccesoHbd
Jdbc6odbc
eeJdCff
%ase de
datos
; ; ; ; ; ;$$n
Figura <$&= Diagrama topolgico de Damecalif
(n la Figura <$&: se presenta el diagrama de despliegue para la misma aplicacin$
(sta no es la )nica alternati+a- pero es la elegida para el e1emplo$
Ceb browser
(quipo#gen2rico
!lataforma# Ywin- uni0Z
consulta
(quipo#Ser+idor6ser+lets
!lataforma# uni0
4ccesoHbd %D
(quipo# Ser+idor6datos
!lataforma# win
;$$n
;
;
Figura <$&: Diagrama de despliegue de Damecalif
(.5.). Componentes + conectores
!ara esta aplicacin se identifican cuatro componentes# web ser+er- Consulta-
4ccesoHbd , %ase de datos$ De 2stas- Consulta , 4ccesoHbd corresponden a
tipos definidos en el 4p2ndice 4- pero con un puerto adicional para establecer
;&E
comunicacin$ (n las Figuras <$<' , <$<; se muestran sus definiciones-
considerando que *eredan de componentes ,a conocidas$
ser+let
consulta
eepuertoff
WrmiHcomunica
@aturaleaQrequerido
Figura <$<' Componente Consulta
Fb1eto remoto
4ccesoHbd
eepuertoff
JdbcHcomunica
@aturaleaQrequerido
Figura <$<; Componente 4ccesoHbd
(l componente Consulta realiar- a grandes rasgos- las siguientes acti+idades#
o Si es in+ocado sin nombre de usuario o sin contrase"a- en+a pgina para
registroI esto lo *ace autosuficiente- sin requerir que la pgina inicial inclu,a
la captura de nombre , contrase"a
o Si tiene nombre de usuario , contrase"a- se intenta conectar con
4ccesoHbd , seg)n la respuesta mostrar a+iso de error o la informacin de
calificaciones correspondiente al usuario$
(l componente 4ccesoHbd tiene como acti+idades ante una solicitud#
o 4bre contacto con %ase de datosI si falla- en+a a+iso
o !ide registro de usuario- con nombre recibido
o Compara contrase"aI si falla- en+a a+iso
o Si contrase"a correcta- solicita calificaciones
o (n+a resultados
(l componente web browser es de tipo gen2rico , se detalla en el 4p2ndice 4$ Su
papel en la aplicacin se reduce a in+ocar a Consulta , mostrar las pginas que
reciba de 2ste$
(l )ltimo componente- %ase de datos- tambi2n es mu, general , se modelar con
un puerto que le permite conectarse con el componente 4ccesoHbd- usando el
;&=
conector 1dbc6odbc$ (n la Figura <$<& se muestra su estructura$ (l puerto se
detalla en el 4p2ndice 4$
eecomponenteff
%aseHdatos
SeleccinQesttica
4daptacinQninguna
4rc*HadaptaQnul
eepuertoff
W1dbcHcomunica
@aturaleaQofrecido
Figura <$<& Componente %ase de datos
(l papel de %ase de datos es el de pro+eer los datos que le sean requeridos$
5nternamente contendr dos tablas# la de usuarios , la de calificaciones$
(n cuanto a los conectores- los tres que se emplean en esta aplicacin estn
descritos en el 4p2ndice 4- por lo cual no se detallan aqu$
(.5.4. <nteracciones
Dentro del caso de uso descrito anteriormente se pueden identificar seis escenas
de interaccin#
i$ 4ccesoHbd se registra
ii$ 3suario in+oca Consulta sin su cla+e
iii$ 3suario in+oca Consulta con su cla+e- pero *a, problemas con
4ccesoHbd
i+$ 3suario in+oca Consulta con su cla+e pero *a, problemas con la %ase
de datos
+$ 3suario in+oca Consulta con su cla+e pero *a, problemas en su nombre
o su contrase"a
+i$ 3suario in+oca Consulta con su cla+e , obtiene la informacin deseada
La primera es id2ntica a cualquier registro ante el conector 9M5- pero se muestra
en la Figura <$<< para que est2 completa la descripcin$
Conector
9M5
4ccesoHbd
9egistro 9ecibe
Solicita.registro-
4ccesoHbd
Figura <$<< 5nteraccin de registro de 4ccesoHbd
;&:
La interaccin correspondiente a in+ocar a Consulta faltando cla+e o contrase"a
se muestra en la Figura <$<B$ @o se detallan las lneas por ser claro su uso$ (s
mu, bre+e- ,a que de inmediato se en+iar la pgina de registro para ser llenada$
Ceb ser+er Consulta
in+oca
!gina de
registro
Figura <$<B 5n+ocacin sin cla+e o sin contrase"a
Las siguientes dos interacciones corresponden a casos donde el usuario se
identifica adecuadamente- pero e0iste alg)n problema de acceso a los datos$ (n la
Figura <$<> se muestra la interaccin correspondiente al caso del componente
4ccesoHbd inaccesible , en la Figura <$<D el caso en que el problema est2 en la
base de datos$ (n 2ste )ltimo caso se de1aron )nicamente los puertos- sin las
lneas especficas- ,a que no *a, confusin , para e+itar que se torne ilegible el
diagrama$
Ceb ser+er
Wcom)n6*tml
Solicitud respuesta
Consulta
Com)n6ser+ Cone0in6rmi
Solicitud respuesta 9egistro 9ecibe
Conector
9M5
5n+oca.nombre-contra/
!gina error .acceso/
Solicita.busca-4ccesoHbd/
error
Figura <$<> !roblema con 4ccesoHbd
;<'
Ceb
ser+er
Wcom)n*tml
Conector
9M5
5n+oca.nombre-
contra/
error
%ase de
datos
1dbc6odbc
Consulta
Com)n6 Cone0in6 WComunica
Ser+ rmi
4ccesoHbd
Comu6 W1dbcnica
odbc
4bre enlace
!gina error
.base datos/
DameHcalif.nombre- contra/
(rror bd
Figura <$<D !roblema en %ase de datos
3na )ltima interaccin que fracasa ocurre cuando el usuario no est registrado o
su contrase"a no corresponde$ esta interaccin se presenta en la Figura <$<E$ (n
ella tampoco se muestran las lneas- para darle legibilidad$
Ceb
ser+er
Wcom)n*tml
Conector
9M5
5n+oca.nombre-
contra/
20ito
%ase de
datos
1dbc6odbc
Consulta
Ser+ rmi
4ccesoHbd
Comu6 W1dbcnica
odbc
4bre enlace
?errorA !gina
error .usuario/
9espuesta# error
!ide usuario
.nombre/
analia
Figura <$<E (rror en identificacin de usuario
La )ltima interaccin que se presenta- mu, similar a la anteriores la que resulta
e0itosa$ Tambi2n en 2sta se omiten las lneas particulares$
;<;
Ceb
ser+er
Wcom)n*tml
Conector
9M5
5n+oca.nombre-
contra/
20ito
%ase de
datos
1dbc6odbc
Consulta
Ser+ rmi
4ccesoHbd
Comu6 W1dbcnica
odbc
4bre enlace
!gina
calificaciones
9espuesta# calificaciones
!ide usuario
.nombre/
analia
!ide
calificaciones
.nombre/
Figura <$<= Consulta e0itosa
(.5.5 ,erfil
Como e0iste un solo caso de uso- los atributos relacionados con el perfil de uso
que se anotarn en la descripcin del caso de uso sern#
posibleHuso# siempre
frecuencia de uso# ;''
:*F Resu#en
(n este captulo se present uno de los aportes principales de este traba1o# el
lengua1e Ar!"ipp$ (n efecto- en la actualidad *a, muc*os esfueros para modelar
componentes- desde di+ersos puntos de +ista , tambi2n se pretende que 3ML
cuente con los elementos necesarios$ Dentro de este panorama- 'ruipp resulta
una propuesta no+edosa- con caractersticas que la distinguen de otros esfueros$
(ntre los puntos importantes de Ar!"ipp se tienen#
o Modela software de componentes con criterio arquitectnico , no slo de
implementacin$ (sto se concreta en la definicin de elementos para
modelar tanto componentes como conectores$
o !resenta +isin topolgica de las aplicaciones- lo que permite un anlisis de
con1unto$ (l diagrama topolgico propuesto difiere de otros usos del mismo
t2rmino en 3ML- los cuales se orientan principalmente al diagrama de
despliegue$
;<&
o (l modelado con 'ruipp est orientado a fa+orecer la preparacin de
pruebas de integracin$ Tal aspecto *a sido mencionado marginalmente en
di+ersos traba1os- pero *a, pocos esfueros concretos en esa direccin- por
lo cual resulta no+edoso$
(n el uso de 'ruipp para e1emplificar elementos de la plataforma Ja+a , un
e1emplo de aplicacin completo- as como otros esfueros no incluidos- se *a
obser+ado que resulta una *erramienta au0iliar en la comprensin de tales
elementos- al realiar abstracciones propias del modelado$ Los beneficios
deri+ados a,udan a preparar me1or las aplicaciones- pre+iendo problemas
potenciales$
(l lengua1e 'ruipp ser la base arquitectnica para las pruebas que se
desarrollan en los captulos > , D- especialmente del )ltimo$
;<<
Ca!0tu)" < Ta8"n"#0a de de$ect"s de
s"$t%are basad" en c"#!"nentes
4ntes de preparar casos de prueba para cualquier software- se tienen que
considerar al menos dos elementos# la naturalea del software , las posibles
fuentes de defectos$ La primera ,a *a sido tratada en captulos anteriores- por lo
cual a*ora *ace falta analiar las fuentes de defectos potenciales$ (sto puede
*acerse de +arias formas- siendo dos las principales# listando defectos conocidos
en la prctica , generando suposiciones a partir de la naturalea del software$ (n
el segundo caso *abr que +erificar su ocurrencia e0perimental$ De cualquier
forma- el modelo de defectos que se forma ser apro+ec*able para todos los
encargados de probar software- para lo cual a,uda muc*o organiarlos de
acuerdo a criterios que a,uden a identificarlos$ 3n con1unto de defectos
clasificados constitu,e una ta0onoma de defectos$ Como alternati+as se pueden
establecer ta0onomas de fallas o de equi+ocaciones- pero es ms com)n
centrarse en los defectos in,ectados al software$
(n este captulo se e0ploran di+ersas fuentes de problemas en el S%C- tanto por
las caractersticas del software en general como aquellas especficas de este tipo
de software$ Se parte de informacin de autores anteriores- deducciones a partir
de la naturalea del software , la plataforma especfica seleccionada , de fuentes
e0perimentales directas- para proceder a organiarlos en un modelo de defectos
que inclu,e su relacin con los orgenes , con las fallas obser+ables$ La
presentacin inclu,e +arios criterios$ Luego se analia la etapa donde se pueden
localiar- para delimitar los que corresponden a pruebas de integracin$
3na +ersin del tema de este captulo- mu, preliminar , con diferencias
significati+as- fue presentada en ?Fernnde- ;:::bA$
;<B
<*4 Pr"b)e#as c"n e) s"$t%are
Cualquier piea de software puede sufrir problemas al tiempo de e1ecucin$ (stos
problemas- que se mostrarn como fallas- pro+ienen de defectos introducidos por
equi+ocacin *umana o de fallas del *ardware$
Las fallas causadas por el *ardware difieren en su tratamiento seg)n su
naturalea$ (n software de tipo monoltico las fallas son generalmente fatales-
especialmente si ocurre en el procesador o la memoria donde se e1ecuta la
aplicacin$ Si el software es distribuido- puede ocurrir una falla parcial- que puede
resultar ms difcil de tratar$ (n este tipo de software se debe contar con
mecanismos que permitan la operacin de los elementos libres de falla$
(n software distribuido- una falla de *ardware aunada con un defecto en el
software puede originar fallas pre+isibles en el software$
(n la preparacin de pruebas para software distribuido- como lo es en muc*os
casos el S%C- se necesitan considerar tanto los defectos relati+os al software en
s- como aquellos relacionados con el mane1o de fallas de *ardware$
5dealmente- se busca e+itar la in,eccin de defectos en el software en desarrollo-
pero siempre *a, remanentes que deben identificarse , corregirse en las pruebas
, a)n en la e1ecucin del software$ (sta identificacin de defectos puede realiarse
al aar- cuando ocurra una falla- pero no es una opcin compatible con un
software de calidad$
La alternati+a es identificar defectos en una forma planeada- que se sir+e
usualmente de una gua o modelo de defectos$ (sta le indica al desarrollador .o al
probador/ qu2 defectos pueden ocurrir en el software$ (ste conocimiento es
acumulati+o , +a creciendo a partir de dos fuentes# la e0periencia , el anlisis de
la naturalea del software , de su desarrollo$ Desafortunadamente a)n no e0iste
un conocimiento completo de los defectos potenciales- ni siquiera para el software
tradicional$
!ara el S%C la e0periencia a)n es mu, escasa- por lo cual )nicamente se cuenta
con la que e0iste para software tradicional , orientado a ob1etos$ (sta e0periencia-
1unto con anlisis tericos- *a sido concretada en di+ersas colecciones de
problemas de software- estudiadas desde el punto de +ista de los defectos- de las
equi+ocaciones originales o de las fallas que causan$ (n la seccin &$;$<$> se
presentaron e1emplos de tales cone0iones o ta0onomas$
(n esta situacin- se debe recurrir al anlisis de las propiedades del S%C , de su
desarrollo para a+eriguar las fuentes de error que pueden lle+ar a defectos en este
tipo de software$ (ste anlisis debe incluir#
Caractersticas del software en general- que se *eredan en el S%C$
@aturalea especfica del S%C$
;<>
4spectos dependientes de la plataforma seleccionada$
Dentro de la naturalea especfica del S%C deben considerarse caractersticas de
los componentes , de su proceso de desarrollo , tomar en cuenta aspectos de
modelado arquitectnico sub,acente- especialmente la interaccin entre
componentes$
(n este traba1o se pretende a+anar en la formulacin de un modelo de defectos
que a,ude a la preparacin de pruebas- para lo cual se analiarn aspectos de la
naturalea del S%C- aspectos de interaccin entre componentes , otros
elementos- que se concretarn en las secciones siguientes$
<*5 .i!tesis es!ec0$icas
Las aplicaciones de S%C se forman a partir de componentes que interact)an$ 4s
pues- para analiar fuentes potenciales de defectos- se partir- por simplicidad- de
la interaccin entre dos componentes- que se resume en la Figura B$;$
3na falla en aplicacin o en el componente de la iquierda puede +enir de tres
causas# falla en el componente de la derec*a- falla en el conector que los une o
una falla en el ambiente$ La falla en el componente de la derec*a puede ser
originado por otro componente- no representado- por el conector que lo une con
ese otro componente o en su ambiente$ La falla de un conector puede originarse
en un defecto de su programacin o de una falla de su ambiente$ 9ecu2rdese que
cada componente , a)n los conectores pueden estar su1etos a diferentes
ambientes$
Componente ; Componente &
Conector
Falla en
aplicacin o en
componente ;
Falla en componente &
Falla en conector
Falla en ambiente
Defecto
Ftro compo$
Falla conector
Falla ambiente
Defecto
Falla ambiente
Figura B$; !roblemas de interaccin
;<D
Detallando un poco ms la situacin de la Figura B$; se obser+a que pueden
agruparse los problemas como en la Tabla B$;$ @tese que *a, diferencias entre
ambos componentes- donde se est suponiendo que el primero .iquierda/
controla al segundo .derec*a/$ (sta situacin es congruente con los aspectos de
interaccin que se tratarn en el Captulo >$
Tabla B$; !roblemas de interaccin
C"#!"nente 4 C"nect"r C"#!"nente 5
Defecto algortmico$
!armetros$
Falta mecanismo de
e0cepciones$
Frden inadecuado$
Falta mecanismo de
impre+istos$
(lementos
desprotegidos$
Defecto interno$
Falla de ambiente$
Falta de recursos$
4+iso inadecuado al
destino$
4+iso inadecuado
de tipo de datos$
5nterfa no coincide$
Defecto interno$
!roblema de
despliegue$
4usencia$
5naccesibilidad$
Falla de ambiente$
@o responde$
9espuesta
inesperada o
parcial$
9espuesta errnea$
Le1ana$
(stado inadecuado$
(n las siguientes subsecciones se tratarn di+ersas *iptesis que se relacionan
con los problemas indicados- unos pro+enientes de la naturalea de los
componentes- otros de su interaccin , otros del ambiente , la plataforma
especfica elegida$
).2.1 ,roblemas en los componentes
4lgunos problemas se deri+an de la naturalea de los componentes- como son#
<*5*4*4 Enca!su)a#ient"
(l encapsulamiento es elemento fundamental del S%C- reforado por las prcticas
comerciales que *acen poco probable contar con el cdigo fuente- a menos que
los componentes , sus deri+ados se desarrollen en la misma empresa$
(l encapsulamiento estricto puede causar problemas por prueba insuficiente del
componente- arrastrando fallas que aparecern al integrarlo con otros$ Tambi2n
puede ocultar funcionalidades no especificadas .de buena o mala fe/ , la
e0istencia de elementos desprotegidos .+ariables p)blicas o protegidas
insuficientemente/$
!or otra parte- al tener )nicamente la informacin de sus interfaces se presentan
problemas de confusin semntica debido a similitudes sintcticas .por e1emplo
una funcin con un nombre sugesti+o pero que realia algo que no es lo deseado/$
;<E
(n las plataformas comerciales se tiene adems poca documentacin acerca de
las interfaces requeridas para la operacin$
3n )ltimo problema asociado con el encapsulamiento es el traslape posible de
funcionalidades entre dos o ms componentes- ,a que se deben emplear
completas$ (l caso contrario- insuficiencia de funcionalidad- no es gra+e porque
siempre se puede e0tender el componente$
<*5*4*5 Reuti)i'acin
La reutiliacin es otra fuente de problemas- pero es parte de la naturalea de los
S%C$ (ntre otros problemas puede tener#
H Ca#bi" de us"# el uso propuesto no es compatible con el original-
pudiendo generar inconsistencias$
H Per$i) di$erente# al emplearse un componente en diferentes conte0tos
+ara su perfil de uso- por lo cual las pruebas que le *a,an sido aplicadas
pueden resultar insuficientes$
H Estad"# algunos componentes son reutiliados sin que se asegure que
se preser+a el estado ni que se restaura el inicial .por e1emplo un ser+let o
un (J% de sesin/I esto puede originar situaciones impre+istas$
H D"cu#entacin insu$iciente# la falta de documentacin puede lle+ar a
problemas de tipo semntico- similares a los mencionados en
encapsulamiento$
Como el software legado es una de las fuentes principales de componentes en la
actualidad- eso sugiere problemas tambi2n legados- como insuficiente
documentacin- pruebas insuficientes- defectos ocultos- ,a sea por compensacin
o falta de propagacin en su ambiente nati+o$
<*5*4*: .erencia
Los componentes- en su ma,ora- usan modelos de ob1etos- que inclu,en alguna
forma de *erencia$ De esta caracterstica se siguen un gran n)mero de problemas
potenciales$ 3no de los ms importantes- similar al que ocurre en ob1etos- es el
*eredar )nicamente el cdigo- sin considerar otros elementos desde los
requerimientos que originaron el componente *asta su dise"o$
Ftros problemas son#
H M1t"d"s 2eredad"s# 4l *eredar- algunos m2todos pueden ser
innecesarios , ocasionalmente da"inosI el problema principal es el uso
innecesario de recursos$
H De!endencias "cu)tas# en el elemento final de una 1erarqua no
siempre son claras todas las dependencias generadas por las diferentes
interfaces- lo que puede originar problemas por elementos ausentes al
tiempo de e1ecucin$
H -a)ta de d"cu#entacin# muc*as +eces no se puede seguir toda la
1erarqua , as se ignoran aspectos presentes en el elemento final$
;<=
<*5*4*< Ada!tacin de) c"#!"nente
Los componentes no deben modificarse- en +irtud de su encapsulacin$ Sin
embargo- para darles fle0ibilidad se permite adaptar una serie de caractersticas-
generalmente a tra+2s de mecanismos que suministra su contenedor$ Tambi2n se
pueden agregar peque"as +ariantes a la funcionalidad en forma de plug6ins- que
pueden +erse como ser+icios especficos- seleccionables dinmicamente o al
momento de despliegue$ !ara emplearlos- al desplegarse inclu,en en el
manifiesto correspondiente$
Las posibilidades de adaptacin , plug6ins ofrecen un buen campo para esconder
defectos# puede causar problemas alg)n +alor o combinacin de ellos- puede estar
ausente un plug6in necesario , que se supone disponible$ 4s pues- deber
tenerse cuidado con estas opciones$
<*5*4*A Intr"s!eccin
(l mecanismo de introspeccin- que se considera parte indispensable de los
componentes- es tambi2n fuente de defectos potenciales- como por e1emplo# un
componente que interroga a otro- puede confundir m2todos o parmetros ,
adems- al ganar conocimiento de la e0istencia , localiacin de otro componente-
puede emplear recursos que no se consideraban disponibles- inclu,endo acceso
no autoriado a +ariables mal protegidas .por e1emplo por usar +alores por omisin
que de1a p)blica una propiedad o un m2todo/$
<*5*4*B D"cu#entacin
4unque se *a mencionado el problema de documentacin en algunos temas
anteriores- debe enfatiarse que- en este tipo de software- es mu, crtica la
documentacin- a pesar de que se confa en la identificacin automtica de
componentes$ 3na mala documentacin traer problemas en la seleccin de
componentes , en su uso- ba1o suposiciones incompletas o errneas$
(n cierta medida la documentacin inclu,e la que proporciona el propio
componente- ,a sea a tra+2s de sus interfaces o de su documentacin de
despliegue- las cuales debieran ser ms e0plcitas de lo que resultan en la
actualidad$
3n aspecto donde puede tener gran impacto es en la descripcin de interfaces ,
sus parmetros- as como el alcance de cada uno de 2stos$ !or raones similares
a la confusin de funciones , *asta componentes- los parmetros pueden
confundirse o desconocerse su importancia$
).2.2 Aspectos e interaccin
Dado que los componentes deben operar con1untamente con otros- qui de
orgenes diferentes- surgen una serie de problemas generales- como son#
;<:
H Versin# se puede esperar una +ersin particular , *allarse con otra-
especialmente en liga dinmica$
H M"de)"s inc"#!atib)es# si *a, +arias plataformas in+olucradas pueden e0istir
conflictos entre modelos .+er ?Garlan et al- ;::>A/$
H Inc"#!atibi)idad# los componentes pueden resultar incompatibles con su
ambiente de software , *ardware- imposibilitando su interaccin$
Ftros problemas relati+os a interaccin son los siguientes$
<*5*5*4 Se)eccin din,#ica
La seleccin de componentes en forma dinmica- inclu,endo plug6ins , casos de
polimorfismo- trae +arios problemas- de los cuales con+iene destacar dos#
H C"n$usin se#,ntica# la liga dinmica confa esencialmente en la descripcin
de interfa- lo cual puede resultar insuficienteI se requiere informacin
dinmica sobre la funcionalidad , sobre requerimientos para operarI adems
e0iste la posibilidad de confundir parmetros$
H Inaccesibi)idad te#!"ra)# un componente conocido puede resultar inaccesible
en el momento que se le requiere- ,a sea porque fue retirado o se encuentra
en uso no compartidoI esto es especialmente frecuente en componentes de
datos$
<*5*5*5 C"nect"r
(l conector empleado puede presentar problemas por defectos de programacin-
pero tambi2n de
H Ag"ta#ient" de recurs"s# los conectores mane1an recursos como
memoria para instancias de componentes- que pueden agotarse$
H Retras"# los conectores pueden sufrir retrasos debido a la cargaI por
e1emplo un conector de 9M5 con pocos componentes sufre retrasos fuertes
al agregarse uno ms$
<*5*5*: Pr"t"c")"
La interaccin entre componentes debe cumplir con el protocolo establecidoI en
algunos casos se puede aceptar cambiar el orden de alguna interaccin- pero en
otras puede resultar problemtico- especialmente en cone0in con problemas de
estado$ Cada conector tiene su protocolo que establece el orden entre acciones de
cada componente , debe ser respetado$
<*5*5*< Distribucin
Las aplicaciones basadas en componentes- como ,a se di1o- son muc*as +eces
sistemas distribuidos- lo que origina di+ersos problemas#
H Retard"# la distribucin siempre origina una cierta latencia que debe ser
pre+ista en la operacin de la aplicacinI en casos e0tremos puede ocurrir que
el retardo .le1ana aparente/ cause un time*out que se confunda con la
ausencia o mal funcionamiento de un componente$
;B'
H -a))a !arcia)# un equipo puede fallar originando una falla parcial del sistema- la
cual se manifiesta de di+ersas formas como falta de respuesta- una e0cepcin
o una respuesta inesperada$
H E8ce!ci"nes# una e0cepcin generada en un componente distribuido se
puede propagar *asta componentes le1anos- que qui carecen de pre+isiones
para ello .+er ?8oas et al- ;::EA/$
<*5*5*A C"#!"nentes c"#!artid"s
Muc*os componentes pueden ser compartidos- lo cual origina problemas en las
interacciones- tales como#
H Estad"# los componentes compartidos- si tienen estado- responden de
diferente forma seg)n el momento en que reciban una interaccin$ 4lgunos
estados pueden ser conocidos- pero no siempre es el caso$
H Ac"!)a#ient" ines!erad"# 4lgunos componentes compartidos pueden
tener mecanismos que generan acoplamiento entre sus clientes- siendo una
fuente potencial de defectosI es el caso del mecanismo de e+entos en
Ja+a%eans- que permite a un cliente bloquear la emisin de e+entos-
afectando as a otros clientes$
H E)e#ent"s "cu)t"s# en ocasiones +arios componentes pueden compartir
un elemento oculto que establece un acoplamiento entre ellosI tal es el
caso de (J% , de ser+lets a tra+2s de mecanismos de adaptacin$
H Pr"teccin# (l uso compartido requiere de proteccin para e+itar colisiones
entre clientesI en el caso de datos se pueden emplear transacciones u otro
mecanismo- pero siempre subsisten problemas potenciales- ,a que no son
fciles de +erificar$
<*5*5*B C"ncurrencia
4lgunos tipos de conector- como es el caso de e+entos- por su naturalea
in+olucran operaciones concurrentes- bien sea a ni+el de *ilo o de proceso$ (stas
operaciones tendrn problemas de sincroniacin , de proteccin de +ariables
compartidas$ (ste problema +a mu, relacionado con el de componentes
compartidos$
).2.( ,roceso e esarrollo
(l proceso de desarrollo de aplicaciones basadas en componentes es diferente a
otros tipos de software- porque su granularidad es ma,or$ Se pueden presentar
problemas en la seleccin de componentes , conectores- especialmente en
contenedores- tanto a ni+el de conectores conceptuales como de su
implementacin particular$
).2.) ,lataforma .ava 2
Como se di1o anteriormente- ninguna de las plataformas comerciales cumple todo
lo que se desea en cuanto a componentes$ 4dems- los lengua1es , con+enciones
acarrean limitaciones particulares sobre las aplicaciones desarrolladas con ellos$
(n el caso de Ja+a se sabe que e0isten problemas potenciales- deri+ados de su
dise"o o de la con+eniencia para los desarrolladores$ 3no de ellos es la falta de
;B;
refuero de la pri+aca de las +ariables$ Tambi2n e0isten problemas en la 1erarqua
de sus clases- como las indicadas en el traba1o de ?4le0ander et al- &'''A- aunque
criticado como poco original$ 5nclusi+e se pueden encontrar defectos en la
documentacin de clases$ Ftra referencia )til en relacin con la seguridad es
?McGraw and Felten- ;::EA
(n los elementos concretos que se usan de la plataforma Ja+a & se encuentran
algunos problemas potenciales que se analiaron en las *iptesis anteriores$
).2.4 ?allas en el ambiente
3na gran fuente de problemas en sistemas distribuidos es el ambiente del
sistema- inclu,endo el *ardware , el software$ _stos pueden tener defectos que se
transmitan al sistema o bien sufrir fallas que afecten su funcionamiento$ (n
especial debe considerarse el subsistema de red$ 4dems de las fallas- pueden
presentarse incompatibilidades entre los componentes , su ambiente$ !or e1emplo
diferencias de la mquina +irtual en que se desarroll , aquella donde se
despliega$
Los problemas de red son mu, +ariados- como puede apreciarse en cualquier uso
de las mismas- inclu,endo problemas fsicos- de carga- de protocolo- de presencia
de elementos necesarios .por e1emplo el 0eb server/ , parmetros de seguridad
dispersos en diferentes aplicaciones , arc*i+os de configuracin$
<*: Cic)" de &ida de de$ect"s
Los problemas con el software pueden +erse en tres tiempos#
i$ E3ui&"cacin# la ocurrencia de la equi+ocacin *umana- intencionada o
accidentalI
ii$ De$ect"# a ra de la equi+ocacin- se produce un defecto que es in,ectado
en el software en alg)n momento de su desarrollo , en alg)n lugar del
softwareI
iii$ -a))a# el defecto puede originar una falla al tiempo de e1ecucin- con un grado
+ariable de se+eridad$
Si e0istiera un problema con una aplicacin- se obser+ar una falla- la cual podr
deberse a un defecto de la implementacin- a una falla en el ambiente o a la
interaccin de ambos$ 4dicionalmente- si se presentan datos susceptibles de
ocurrir- pero fuera de las especificaciones- puede tambi2n ocurrir una falla$ (ste
sera un problema de robuste- que puede ser gra+e en software de empresa
como es el S%C$
4l atender la falla debern cuidarse dos aspectos#
H L"ca)i'ar !r"b)e#a# identificar el elemento o grupo de elementos
donde se presenta- los cuales inclu,en componentes- conectores- equipos-
redes , software del ambiente$
;B&
H Va)"rar c"nsecuencias# para decidir si es necesario reemplaar un
elemento- modificarlo o tolerarlo como est$
Ftro aspecto importante- sobre todo para me1orar el proceso de desarrollo- es el
identificar la etapa donde se in,ect el defecto$
!or )ltimo- al tratar la posible equi+ocacin que caus la falla- debe considerarse
la intencionalidad , la naturalea de la equi+ocacin$
(n las secciones siguientes se detallan los tres momentos asociados con
problemas en el S%C$ Se eligi comenar por la falla- ,a que ser el resultado
obser+ado o sntoma del problema$
).(.1 ?allas observables
La primera etapa de un problema de software en ser obser+ada es la ocurrencia
de una falla- que puede ser desde una peque"a des+iacin en el resultado *asta
una p2rdida del control de la aplicacin , da"os a los recursos .arc*i+os
principalmente/ en casos e0tremos$
(n el caso de las fallas- adems de saber su tipo- es necesario precisar la
localiacin$ (sta localiacin puede ser menos detallada que la que se present
en la seccin de defectos , de *ec*o operan con1untamente como au0iliares en la
identificacin , correccin de problemas$
@o todas las fallas son igualmente importantesI algunas afectan solamente la
presentacin de los resultados- mientras otras los presentan incompletos o
errneos$ 4)n cuando nadie desea utiliar software que ocasiona fallas- en
muc*os casos se tolera *asta cierto punto- especialmente cuando no *a,
alternati+as$ (n el caso del S%C es mu, posible que los componentes e0istentes
presenten alguna falla con respecto a las especificaciones de la aplicacin- pero
que no sea de gra+edad$ (n esos casos tal +e sea necesario utiliarla$ 4s- una
+aluacin de la gra+edad de la falla permitir tomar una decisin acerca de su
aceptacin$
4 continuacin se presentan las fallas desde tres puntos de +ista# su tipo gen2rico-
su localiacin , sus consecuencias o gra+edad$
Las fallas- cualquiera que sea su tipo- pueden ocurrir#
i$ ocasionalmente- al aar
ii$ para algunas combinaciones de datos- de carga o de tiempo
iii$ siempre
(l caso ms gra+e pudiera ser el tercero- pero es ms difcil aislar el problema en
el primer caso$
;B<
<*:*4*4 Ti!"s de $a))a
Las fallas se pueden agrupar en unos pocos tipos como se muestra en la tabla
B$&$ Los diferentes tipos pueden ser asociados con la gra+edad que se presenta
ms adelante$
Tabla B$& Tipos de falla
Ti!" Descri!cin E6e#!)"s
De1a de operar$
(l sistema o parte del
mismo de1an de
operar- al menos
como lo percibe el
usuario del mismo$
Totalmente$
!arcialmente- slo
algunas funciones o
nodos$
4parente .parece no
*acer nada por falta
de retroalimentacin/$
Falla en resultados
+isibles$
Los resultados
presentan alguna
diferencia con lo
esperado$
Formato# slo
presentacin$
8alores# alg)n +alor
difiere del esperado$
Tipo# un dato es de
tipo incorrecto$
4usencia# falta un
dato que se esperaba$
!roblema en datos
permanentes$
Los datos
permanentes
.arc*i+os- bases de
datos/ tienen
problemas$
8alores equi+ocados$
5nconsistencia de
datos$
%asura# datos
obsoletos o
temporales que
debieron remo+erse$
9esultado fuera de
tiempo
@o se cumplen
requerimientos de
tiempo
9etardo$
4nticipo$
!2rdida de secuencia$
Falla al escalar
La falla se presenta al
incrementar el
+olumen de datos o el
n)mero de procesos
concurrentes .por
e1emplo los clientes/
Funciona *asta cierto
ni+el , luego falla
bruscamente$
;BB
!roblema de
funcionalidad
Las funciones son
ms o menos de las
necesarias$
5ne0istente# falta una
funcin necesaria$
Duplicada# dos o ms
funciones traslapadas$
5nnecesaria# e0isten
funciones adicionales
no necesarias$
5nesperada# una
funcin adicional que
act)a
inesperadamente$
!roblema con
e0cepciones$
Las e0cepciones son
mal mane1adas-
originando problemas$
@o generada# no se
a+isa de una situacin
especial$
@o atrapada# no se
esperaba que
ocurriese$
Mal procesada# la
e0cepcin se atrapa
pero no se trata
adecuadamente$
Despliegue$ !roblema al desplegar
alg)n componente$
5ncompatibilidad con
el ambiente o
plataforma$
!roblema de
+ersiones$
8alores de adaptacin
inadecuados$
Falta plug6in$
Concurrencia
!roblemas deri+ados
de la e0istencia de
concurrencia entre
componentes$
9endimiento# se
reduce$
4gotamiento de
recursos# por e0ceso
de elementos$
%loqueo# el sistema se
bloquea por *aber
demasiados
componentes$
!2rdida de datos# por
falta de sincrona$
Duplicacin de datos#
por falta de sincrona$
;B>
<*:*4*5 L"ca)i'acin de )a $a))a
Las fallas- como se di1o al principio de este captulo- pueden deberse a la
aplicacin concreta o bien al *ardware o al software de la plataforma , otras
*erramientas au0iliares- como el de red$ (s posible que- dependiendo de
diferentes responsables- todos prefieran atribuir el problema a otra parte del
sistema completo$ !or ello es de importancia poder determinar la localiacin de la
falla$
!ara identificar dnde ocurre la falla se procede en tres pasos#
i$ L"ca)i'acin $0sica# identificar el nodo o segmento de red donde se presenta
el problema$
ii$ L"ca)i'acin )gica# *abiendo identificado un nodo- identificar el proceso o
segmento de comunicacin entre procesos donde ocurre la falla$ (sto permite
identificar un grupo de componentes responsables$
iii$ L"ca)i'acin $ina)# Dentro del grupo identificado- detallar la identificacin
*asta *allar el componente- conector o elemento de la plataforma o ambiente
donde se inici la falla$
La localiacin de la falla no debe confundirse con la localiacin del defecto- de lo
que se tratar ms adelante$ 4qu no se busca identificar el defecto que origina la
falla- sino la fuente aparente del problema$
<*:*4*: C"nsecuencias
(l criterio de consecuencias organia los defectos seg)n la gra+edad de la falla
generada$ (s sabido que algunos defectos no se propagan al e0terior- porque son
cancelados por otra instruccin o +alidacin .+er traba1o de ?Mic*ael , Jones-
;::DA/- de modo que pueden ignorarse en ciertos casos .sobre todo si no es
software crtico/$ Ftros defectos pueden compensarse , algunos son ine+itables$
Dentro de estos )ltimos los *a, ligeros- que )nicamente afectan detalles de
presentacin- otros que producen datos incorrectos- *asta llegar a los que da"an
las bases de datos o pierden el control$ (n la Tabla &$B se mostraron algunas
fallas seg)n su se+eridad- de acuerdo con %eier$
!or lo general- en las ta0onomas e0istentes para software desarrollado
tradicionalmente- no aparece este criterio- ,a que no se busca lograr software que
presenta fallas- sino careciendo de ellas lo ms posible .aunque se tolere
comercialmente la +enta de productos con defectos conocidos/$ Sin embargo- en
el caso de software basado en componentes- muc*as +eces se tendr que
emplear componentes pree0istentes .)nica +ersin o software legado/ , se tendr
que tolerar que presenten fallas- mientras no causen da"os ma,ores$ De *ec*o
*a, un cambio de 2nfasis en el desarrollo de componentes para tolerar la
interaccin con elementos dudosos .+er por e1emplo el traba1o de ?8oas et al- ;::E
bA/$
;BD
(ste criterio- que se resume en la Tabla B$<- a,udar a estimar la gra+edad de las
fallas , as poder tomar decisiones acerca de la con+eniencia de incorporacin de
componentes , otros elementos necesarios para una aplicacin de S%C$ !or
supuesto- la gra+edad debe e+aluarse en relacin con el sistema propuesto , el
punto de +ista de los desarrolladores$
La tabla B$< muestra las categoras propuestas .subra,adas/ , algunos e1emplos
.sin subra,ar/$ Como se di1o- dnde ubicar cada falla depender de las intenciones
del usuario , del desarrollador$
Tabla B$< Fallas de acuerdo a sus consecuencias$
Ign"rab)es
Funciones innecesarias
C"#!ensab)es
Funcin ine0istente
Tiempo de respuesta
E&identes
M")est"s
Cosm2ticos .formato/
De sinta0is
Gra&es
Dato equi+ocado
Dato ignorado
!roblema de lmites
Mu( gra&es
(0cepcin impre+ista
Da"o a datos permanentes
!roblema en componente distribuida
).(.2 &efectos en la aplicacin
Las diferentes equi+ocaciones o la +oluntad de introducir cambios- generan
defectos potenciales en el software- los cuales se manifiestan en di+ersas formas-
que inclu,en cdigo de ms o de menos- defectos en algoritmos , estructuras de
datos , cambio de smbolos$ (stos defectos importan no slo en su tipo sino
especialmente por su localiacin- es decir- en que elemento concreto ocurren- en
este caso componentes o conectores$ 3n aspecto ms que sir+e como
retroalimentacin al proceso de desarrollo- es la identificacin del momento en que
fue in,ectado el defecto- a lo largo del ciclo de +ida$ Los defectos ms duraderos ,
problemticos son los que se introducen en las primeras etapas de desarrollo ,
permanecen ocultos *asta que se encuentra mu, a+anado$ 4 continuacin se
presentan tres formas de +er los defectos# los diferentes tipos- su localiacin , el
momento de in,eccin$
;BE
<*:*5*4 Ti!"s de de$ect"s
La clasificacin de defectos en +arios tipos puede parecer de poca importancia-
pero es rele+ante cuando se trata de preparar pruebas- ,a que la manera de lograr
su manifestacin puede ser diferente$ 4dems- se pueden establecer cone0iones
entre los defectos- seg)n su tipo- , su posible origen- lo cual se apro+ec*ar para
el me1oramiento del proceso de desarrollo$
(n la tabla B$B se presenta una lista de tipos de defectos del software basado en
componentes- con e1emplos tpicos$ 4lgunos son comunes con otros tipos de
software- pero los dems son propios del S%C$
Tabla B$B Tipos de defectos
Cdigo adicional
!orcin de cdigo
que no corresponde
con las funciones
especificadas
Funcin adicional$
Camino adicional$
Defecto algortmico
4lgoritmo defectuoso
en relacin con el
propsito original
Defecto lgico
Defecto en estructura
de datos
La organiacin de
los datos no es
adecuada$
8ariables
desprotegidas
Cambio de smbolo
3n smbolo .operador
u operando/ fue
cambiado por otro-
probablemente similar
Cambio de operador
.e en +e de /$
Cambio de +ariable$
Lmites cambiados$
!armetro cambiado$
!roblema de lmites Los lmites de un ciclo
o estructura de datos
no son correctos
Lmite de ciclo
e0cedido por una
unidad$
@o se considera el fin
de un stream$
Funcionalidad
duplicada
Dos o ms
componentes
implementan una
misma funcionalidad
Dos funciones que
realian una misma
funcin$
Tipo de datos
Seleccin equi+ocada
de tipo de datos que
impide escalamiento
o resultan
incompatibles
4signar int en +e de
long$
Tipo de parmetro
efecti+o incompatible
con tipo de parmetro
formal
;B=
Defectos de sincrona
5ne0istencia de
mecanismo de
sincroniacin entre
*ilos o procesos
4usencia de
sincroniacin
Defecto de iniciacin
Componente no
inci+iliado
correctamente
Componente
reutiliado sin cuidar
iniciacin$
5niciacin *eredada
con problemas
Defecto en protocolo$
(l protocolo de
comunicacin entre
componentes- de
acuerdo al conector
elegido- no se
respeta$
Secuencia
inaceptable de
comandos$
!roblema de registro$
3n componente
quiere *acer uso de
ser+icios para los
cuales no est
registrado$
5ntento de usar ob1eto
9M5 no registrado$
(sperar e+ento sin
registrarse como
escuc*a$
Defecto en
despliegue$
4l desplegar se
introduce un defecto$
!lug6in equi+ocado$
8alor inadecuado en
propiedad$
8ersin incorrecta de
componente$
!roblema de
e0cepcin$
3na e0cepcin no es
atendida como
debera
(0cepcin no
generada- e0cepcin
no atrapada-
e0cepcin no
atendida
Defecto en mane1o de
fallas$
@o se tiene
mecanismo adecuado
para el caso de una
falla$
4usencia de
mecanismo$
@o pre+isin de timeout$
Defecto en
comunicacin con
usuario$
(l sistema no tiene
mecanismos
adecuados de
comunicacin con el
usuario$
4usencia de
retroalimentacin$
9etroalimentacin
ambigua$
;B:
Defecto en
parmetros$
Los parmetros
tienen uno o ms
problemas$
@)mero de
parmetros$
Frden de parmetros$
8alor de un
parmetro$
Tipo del parmetro$
Confusin semntica$
Dependencia de
+ersin$
Se apro+ec*a la
e0istencia de un
defecto para realiar
una funcin$
3so de un defecto en
la plataforma$
4pro+ec*ar un
acoplamiento oculto$
Concurrencia$
@o se mane1a
adecuadamente la
concurrencia$
@o pre+er seguridad$
4usencia de
proteccin a recursos
compartidos$
Documentacin$
La documentacin no
corresponde con la
+ersin del software$
Funcin documentada
, que opera diferente$
8alor lmite diferente
al efecti+o$
<*:*5*5 L"ca)i'acin
!ara aquellos encargados de corregir defectos o e+aluar partes concretas de una
aplicacin de S%C- lo ms urgente puede ser identificar dnde se encuentran$
5ndependientemente de la arquitectura particular de la aplicacin- se pueden *acer
*iptesis sobre los posibles lugares donde ocurren ciertos tipos de defecto$
La localiacin del defecto es continuacin del traba1o de localiacin de una falla
.+er seccin anterior/$ (n esta etapa slo interesan defectos en el software , ,a no
se consideran las fallas del *ardware$
4 grandes rasgos- las fallas pueden ser causadas por defectos localiables en un
elemento especfico- pudiendo ser las componentes concretas- los conectores
empleados- el software de soporte o la plataforma- pero tambi2n pueden
originarse en defectos de interaccin- no atribuibles a un solo elemento$ !or la
naturalea de este traba1o- este tipo de defectos interesan especialmente$
4*ora bien- los defectos de interaccin pueden ser difciles de tratar- ,a que puede
darse el caso de que todos los elementos est2n libres de defectos .al menos en
relacin con la falla obser+ada/$ 4s pues- tales defectos son atribuibles a alguno
de los procesos que lle+aron a ensamblar una aplicacin particular$
4s pues- los defectos sern localiables en
3n elemento especfico$
3n proceso de preparacin$
;>'
(n cuanto a los elementos- e0isten cuatro posibilidades#
Componentes$
Conectores$
!lataforma de software- inclu,endo redes , software au0iliar$
Documentacin$
(n lo relati+o a los componentes- a)n cuando pueden +erse como unidades- en la
prctica deben considerarse +arias partes donde puede residir el defecto .+er
Figura B$&/#
i$ (l cuerpo principal del componente
ii$ Sus puertos .interfaces ofrecidas , requeridas/
iii$ Las +ariables accesibles para adaptacin
i+$ Los plug6ins para adaptacin
+$ (l o los arc*i+os de manifiesto para despliegue
c"#!"nente
!lug6ins
8ariables
adaptables
Figura B$& !artes de un componente
(n cuanto a los conectores , la plataforma- son elementos e0ternos que estn
dados , que- se sabe por la e0periencia- nunca estn libres de defectos$
La documentacin se inclu,e ,a que es un producto de software mu, necesario ,
usualmente fuente de problemas$ 3n defecto en la documentacin puede originar
problemas en la operacin de un elemento o de una aplicacin$ Fcurre con
frecuencia que la documentacin de un producto de software se encuentre mal
sincroniada con las +ersiones del producto- lo que origina inconsistencias en el
uso de la informacin que suministra$ (s com)n- por e1emplo- que una funcin que
se reporta ,a no e0iste o se *a modificado su usoI tambi2n que un +alor lmite
*a,a cambiado$
(n cuanto a los procesos que pueden lle+ar a problemas de interaccin se tienen#
Dise"o arquitectnico de la aplicacin$
Seleccin de elementos .componentes , conectores/ para una aplicacin$
Despliegue de elementos$
;>;
(l proceso de dise"o arquitectnico puede introducir defectos gra+es , difciles de
identificar$ (stos pueden lle+ar a interacciones problemticas- sin que sea
responsabilidad de un elemento particular$
(l proceso de seleccin de elementos es ms concreto que el anterior , puede
originar muc*os problemas$ 4lgunos pueden ser#
4gotamiento de recursos# Si se eligen +arias componentes demasiado
grandes en relacin con la funcionalidad que se espera de ellas- el efecto
acumulado puede lle+ar a quedarse sin recursos , generarse una falla$
(fectos secundarios# Si dos componentes *acen las funciones que se
esperan pero una de ellas *ace algo ms- eso puede representar efectos
secundarios al tiempo de e1ecucin$
Diferencia de escala# 4)n cuando las funciones de dos componentes sean
compatibles- pueden e0istir problemas de lmites o de inter+alo de +alores
aceptados .por e1emplo en uno ser enteros de ;D bits , en otro enteros de
<& bits$
!or )ltimo- el proceso de despliegue resulta en defectos muc*o ms concretos
que los anteriores- ,a que se reducen a seleccionar mal la +ersin de un elemento-
asignar +alores inadecuados a una propiedad o ignorar alg)n requerimiento para
que operen adecuadamente- como pueden ser los directorios o caminos .paths/$
La Tabla B$> resume las posibles ubicaciones de los defectos$
Tabla B$> Localiacin de defectos
L"ca)i'acin E6e#!)"s
Componente#
Cuerpo principal$ Defecto algortmico$
!uertos$ Frden de parmetros$
!ropiedades$ 8alor inadecuado$
!lug6ins$ 4usencia$
4rc*$ Manifiesto$ 4usencia o +alor inesperado$
Conector$ Defecto algortmico$
!lataforma$ Tipo errneo de parmetros$
Documentacin$ 8alor lmite inconsistente$
!roceso de dise"o
arquitectnico$
9esponsabilidad de funcin
mal repartida entre
componentes$
!roceso de seleccin$ Funcin traslapada$
!roceso de despliegue$ 8ersin equi+ocada$
(n el caso de los componentes- (l criterio de localiacin ser )til para#
a/ Localiar el defecto , poder corregirlo .si se est en desarrollo/-
compensarlo .si no *a, otra solucin/ o desec*ar el elemento donde
;>&
aparece- si es posible$ Si e0isten componentes alternas con funcionalidad
equi+alente , una tiene .ms/ defectos- puede preferirse a la otra$ La
compensacin puede ser a tra+2s de un wrapper o en+oltura que aisle el
elemento$
b/ (studiar cul elemento es el que presenta ms problemas- para +igilarlo
me1or durante el mantenimiento$
c/ Separar los defectos localiables de aquellos que correspondan a la
interaccin , por tanto estn distribuidos$
d/ 4signar confiabilidad a elementos , aplicaciones enteras$
<*:*5*: M"#ent" de in(eccin
De acuerdo con datos colectados en la industria se sabe que- para software
con+encional- la gran ma,ora de los defectos se producen en la etapa de
establecimiento de requerimientos .>Db/ frente a un Eb en la etapa de
codificacin ?Uit- ;::>A$ Se sabe tambi2n que los defectos introducidos en las
primeras etapas son los ms difciles de identificar$ !or esto con+iene analiar los
posibles momentos de in,eccin de defectos$
(l momento de in,eccin de un defecto depende del modelo de desarrollo , ciclo
de +ida que se usan como referencia$ (l software basado en componentes tiene
su peculiar ciclo de +ida al cual se referir esta seccin$ Tomamos como base lo
asentado en la seccin ;$<$<
Cic)" de &ida de s"$t%are basad" en c"#!"nentes
Las principales etapas del desarrollo de software basado en componentes son#
a/ (stablecimiento de requerimientos# en esta etapa se conceptualian los
componentes de negocios , su cone0in- a ni+el abstracto$
b/ 4nlisis# en esta etapa se detalla el conocimiento de los componentes ,
se identifican las clases ms importantes en cada uno$
c/ Dise"o# se sigue detallando la naturalea de los componentes , su
interaccin$
d/ 5mplementacin$
e/ !rueba de unidad de componentes desplegados$
f/ (nsamble de grupos de componentes
g/ !ruebas de integracin de grupos de componentes$
*/ !ruebas de sistema$
i/ !ruebas de aceptacin$
Si se emplearn componentes pree0istentes- de la propia empresa o disponibles
comercialmente- los pasos c/ , d/ se +eran reemplaados por#
1/ Seleccin de componentes
7/ Seleccin de elementos de la plataforma que se emplearn
.especialmente conectores/$
l/ 5nstalacin de los elementos de la plataforma seleccionados$
;><
(n realidad el m2todo ser iterati+o , el ensamble ser progresi+o$ !or la
naturalea de este tipo de software el desarrollo es sumamente concurrente , as
+arias de las fases pueden realiarse en paralelo$
M"#ent"s de !"sib)e in(eccin*
De las di+ersas fases del ciclo de +ida presentado arriba- todas son posibles para
la in,eccin de defectos en el software- ,a que en todas ellas se pueden cometer
errores$ !or e1emplo- en la recoleccin de requerimientos es fcil omitir alguno
importante o documentar inadecuadamente alguno de ellosI en las etapas de
pruebas- un caso de prueba mal preparado puede lle+ar a una falsa KcorreccinL
para un problema ine0istente- o a la omisin de un defecto e0istente$
4dicionalmente a las fases del ciclo de +ida del software basado en componentes-
*a, otro momento en que puede in,ectarse problemas# al tiempo de la seleccin
del software intermedio o durante el desarrollo del mismo$
4lgunas etapas pueden descomponerse en subetapas que tal +e con+enga
distinguir si se trata de e+itar la proliferacin de defectos$ !or e1emplo- la
implementacin de componentes lle+a una etapa de codificacin , luego una de
empaque$ (sta )ltima no se refle1a en el cdigo- pero s en las propiedades del
sistema despu2s de ser desplegado el componente$ Ftro tanto ocurre con el
ensamble de grupos de componente o del sistema completo- donde otra +e se
deben crear descriptores empleados al tiempo de despliegue , que pueden alterar
sensiblemente el funcionamiento del sistema$
Ftro aspecto rele+ante es el despliegue de componentes dinmicos- que se unen
al sistema en el )ltimo momento , que por tanto no pueden +erificarse
ampliamente$
Tabla B$D Defectos de acuerdo al momento de in,eccin$
Eta!a M"#ent" E6e#!)"
Desarrollo de
componente o
conector
(specificacin
Dise"o
Codificacin
!ruebas de unidad
(mpaque
Documentacin
Mantenimiento .control de
+ersiones/
Defectos algortmicos$
Defectos en
documentacin$
Funcionalidades ocultas$
;>B
Desarrollo de
aplicaciones
Dise"o arquitectnico
Seleccin de
componentes
Seleccin elementos de
plataforma$
5nstalacin elementos
plataforma$
5ntercone0in de
componentes
Despliegue
Seleccin dinmica
!ruebas
Funcin ambigua$
8alor inadecuado en
despliegue$
8ersin equi+ocada$
Finalmente- debe considerarse la etapa de mantenimiento$ (n este tipo de
sistemas esta etapa re+iste gran importancia porque se debe dar mantenimiento a
componentes indi+iduales as como a aplicaciones completas- lo cual puede lle+ar
a gran n)mero de oportunidades para cometer equi+ocaciones$
(l criterio de momento de in,eccin es de utilidad para#
H estudiar , me1orar el proceso de desarrollo- especialmente las etapas
ms propensas a producir defectosI
H planificar me1or las pruebas en cada etapa$
).(.( *!"ivocacin 0"mana e intencionalia
La causa )ltima de cualquier problema e0istente en el software- aparte de fallas en
el *ardware- es alguna equi+ocacin *umana o un problema intencional- *umano
tambi2n$ (l concepto de equi+ocacin es com)n a todos los anlisis del software-
tanto tradicional como orientado a ob1etos o basado en componentes$ Sin
embargo la intencionalidad no se tomaba en cuenta- e0cepto para referirse a
temas de seguridad$ (sta situacin deri+a de la forma de desarrollo del software-
donde se tena acceso a la ma,or parte de cdigo- con e0cepcin de algunas
bibliotecas$
(l caso del S%C es diferente- ,a que se incorporan elementos a1enos sin acceso a
su cdigo fuente$ 3n factor adicional- de importancia cuando se usa software de
di+ersas fuentes- es la creciente presencia del software malintencionado- oculto
dentro o ligado con software inofensi+o$ Todo ello obliga a considerar como
fuentes iniciales de los defectos tanto la equi+ocacin como la intencionalidad$
Las modificaciones a las especificaciones sin mala intencin se +uel+en un
problema cuando quedan sin documentacin adecuada$
(l software malicioso inclu,e +arios casos- desde de1ar pre+isiones para usos no
autoriados de los datos *asta la implantacin de bombas de tiempo$
;>>
(n la tabla B$E se muestra una lista de categoras relacionadas con el origen de un
problema de software por equi+ocacin *umana o por intencin$
3tiliar el criterio del origen tiene di+ersas aplicaciones para#
H e+itarlos estudiando las causas conocidasI
H planificar me1or las pruebas en cada etapa$
H considerar la estrategia de solucin cuando se *a identificado uno de 2stos
.considere por e1emplo la diferencia que *ar saber que es una modificacin
consciente , de buena fe frente a la posibilidad de un +irus malicioso/$
Tabla B$E$ (qui+ocaciones e intencin de acuerdo al origen$
Intenci"na)es
Ma)ici"s"s
Caballo de Tro,a
8irus
%omba de tiempo
!uerta oculta
4lteracin de funcin
N" #a)ici"s"s
Canal encubierto
Me1ora no documentada
4,uda a implementacin
3so de defectos en plataforma
N" intenci"na)es
(qui+ocacin en obser+acin
(qui+ocacin en requerimientos
(qui+ocacin en modelado
(qui+ocacin en dise"o
(qui+ocacin en implementacin
Mala documentacin
(qui+ocacin de reuso
@o considerar concurrencia
Falta de conocimiento del modelo
bsico
Falta de conocimiento de
elementos usados
(qui+ocacin al seleccionar
elemento
5gnorar e0cepciones posibles
(qui+ocacin en despliegue
Las equi+ocaciones intencionales se manifiestan principalmente dentro de los
aspectos del producto final que no se encontraban en las especificaciones- ,a que
son parte de la funcionalidad agregada$ Sin embargo pueden aparecer como
des+iaciones respecto a las especificaciones originales- confundi2ndose con
equi+ocaciones inocentes$ Las equi+ocaciones no intencionales pueden ocurrir en
;>D
la funcionalidad especificada , tambi2n en la parte agregada- ,a que no puede
asegurarse que est2 libre de defectos$ 4l respecto puede recordarse el llamado
gusano que origin grandes problemas a redes de mquinas operando ba1o 3ni0-
cu,as consecuencias fueron ms consecuencia de una equi+ocacin en la
programacin que del propsito del autor$
<*< Resu)tad"s ( c#" usar)"s
Los resultados presentados en la seccin anterior requieren tratamiento con1unto
as como relacionarlos con otros elementos para que resulten de ms utilidad$ (n
esta seccin se relacionan las tres etapas de los problemas de software .su
origen- el defecto , la falla/- con los ni+eles de prueba , se bosque1a la manera de
usar esta informacin- que es una parte de la liga con los siguientes captulos$
).).1 Asociacin e res"ltaos
(n la seccin anterior se e0aminaron los problemas de software en sus orgenes-
como defectos concretos , como fallas obser+ables$ !ara sacarle pro+ec*o a esa
informacin con+iene relacionar los tres aspectos$
3na misma falla puede ser causada por diferentes defectos- mientras que un
defecto puede tener di+ersos orgenes$ 5n+ersamente- una misma equi+ocacin
puede generar diferentes defectos , un mismo defecto- dependiendo de las
condiciones- puede originar diferentes fallas$
Tabla B$= 4sociaciones origen6defecto6falla
Origen De$ect" -a))a
(qui+ocacin en
requerimientos$
(qui+ocacin en
dise"o$
(qui+ocacin en
codificacin$
Defecto de
retroalimentacin$
!roblema de
Jardware$
!roblema de
software$
Falla en nodo$
(qui+ocacin en
dise"o$
(qui+ocacin en
codificacin$
Defecto algortmico
en componente$
(qui+ocacin en
dise"o$
(qui+ocacin en
codificacin$
Defecto algortmico
en conector$
De1a de operar
parcialmente$
;>E
(qui+ocacin en
requerimientos$
(qui+ocacin en
codificacin$
Defecto algortmico$
(qui+ocacin en
requerimientos$
(qui+ocacin en
seleccin de
componente$
Tipo de datos
incorrecto$
(qui+ocacin en
documentacin$
Defecto en
documentacin$
9esultados +isibles
errneos$
(qui+ocacin en
requerimientos$
(qui+ocacin en
documentacin$
(qui+ocacin en
seleccin de
componentes$
Tipo de datos
incorrecto$
(qui+ocacin en
requerimientos$
(qui+ocacin en
dise"o$
Defecto de a+iso de
lmites$
Falla de
escalamiento$
5ntencionalidad por
creati+idad$
5ntencional por
malicia$
(qui+ocacin en
codificacin$
Defecto algortmico$
(qui+ocacin en
documentacin$
(qui+ocacin en
seleccin$
Defecto en +ersin$
Funcionalidad
adicional$
(qui+ocacin en
dise"o$
(qui+ocacin en
codificacin$
(0cepcin no
atrapada$
(qui+ocacin en
dise"o$
(qui+ocacin en
codificacin$ (0cepcin mal
atrapada$
!roblema con
e0cepcin$
;>=
5ntencional- malicioso$
(qui+ocacin en
codificacin$
Defecto algortmico$
(qui+ocacin en
requerimientos$
(qui+ocacin en
codificacin$
Defecto en mane1o de
concurrencia$
(qui+ocacin en
codificacin$
(qui+ocacin en
seleccin$
Defecto en conector$
(qui+ocacin en
codificacin$
Defecto en
plataforma$
Datos permanentes
da"ados$
(qui+ocacin en
documentacin$
Defecto de
documentacin$
(qui+ocacin en
requerimientos$
(qui+ocacin en
codificacin$
Defecto algortmico$
(qui+ocacin en
dise"o arquitectnico$
(qui+ocacin en
despliegue$
Defecto de
distribucin$
!roblema de
Jardware$
!roblema de
Software$
(qui+ocacin en
seleccin$
!roblema de red$
9esultado fuera de
tiempo$
Como el inter2s principal de este traba1o es la prueba del software- el elemento
fundamental que se obser+a es la ocurrencia de una falla- por lo cual se reuni la
informacin en la Tabla B$= que presenta tres columnas# la derec*a presenta
fallas- la central defectos que pueden originar las fallas , la iquierda los posibles
orgenes de los defectos$ !ara leerse- un grupo de filas de la derec*a pueden
originar una sola del centro , +arias del centro una sola de la iquierda$ La tabla no
es e0*austi+a , debe recordarse que los problemas de software pueden seguir
muc*os caminos- dependiendo de las condiciones- por lo cual no siempre son
determinsticos$
).).2 &efectos por nivel e pr"eba
3n aspecto interesante es el ni+el de pruebas donde se puede esperar localiar un
defecto particular$ (n el caso de software tradicional se localian muc*os defectos
en el curso del propio desarrollo- sin esperar a las pruebas$ !or e1emplo-
?\amaura- ;::=A informa que en la compa"a donde traba1a eliminan muc*os
;>:
defectos al preparar los casos de prueba- en forma paralela con el desarrollo$ Ftra
forma popular de identificar anticipadamente muc*os de los defectos son las
re+isiones t2cnicas ?Uan- ;::EA$ 4*ora bien- en el caso del S%C no se est en
posibilidad de apro+ec*ar tales +enta1as- por lo cual las pruebas tienen ms peso$
Como en este traba1o interesa en especial el ni+el de integracin- resulta
importante organiar los defectos por ni+el de prueba donde ms probablemente
podrn aparecer$ Los resultados se muestran en la tabla B$: donde se listan los
defectos mostrados en la tabla B$B , las etapas donde pueden identificarse$ La
tabla marca las etapas donde se espera localiar cada tipo de defecto$
Tabla B$: Defectos seg)n ni+eles de pruebas$
!ruebas de integracin Defecto !rueba
de
unidad
8erificacin
inicial
Fperabilidad 5nteraccin
!ruebas
de
sistema
Documentacin

Defecto
lgico

(structura de
datos

Cambio de
smbolo
Lmites
5niciacin
(0cepciones
Comunicacin
usuario

!armetros
Cdigo
adicional

Funcin
duplicada

8ersin
Tipo de datos
Sincrona
!rotocolo
9egistro
Despliegue
Mane1o de
fallas

Concurrencia
;D'
).).( @tilizacin e res"ltaos
Los elementos tratados en este captulo- que conforman un modelo de defectos-
tienen +arios usos posibles- como se muestra en la Figura B$<$
(l uso que interesa en este traba1o es el relacionado con pruebas- que *ar uso
del modelo de defectos 1unto con el modelo arquitectnico de una aplicacin-
empleando los elementos del captulo <$ De una combinacin de ambos se
pueden generar reglas de generacin de pruebas- mismas que pueden llegar a
automatiarse$ (ste enfoque es la materia de los dos captulos que siguen$
(l otro uso es complementario , puede darse dentro del proceso de pruebas o
fuera del mismo$ (ste enfoque parte de la ocurrencia de una falla , del deseo de
identificar las posibles causas para corregirlas$ (sto es el proceso de depuracin
de software$ !ara lograrlo se emplea el modelo arquitectnico como una gua
sobre la que se aplica el modelo de defectos- buscando identificar la localiacin
del posible defecto .o defectos/$
La depuracin apro+ec*a los elementos tratados ba1o el tema localiacin de fallas
, localiacin de defectos que se trataron en la seccin B$&$
Modelo arquitectnico
Modelo arquitectnico
Modelo de defectos
Defectos posibles , localiacin
!ruebas sugeridas
Fallas obser+adas
.resultados/
Figura B$< 3sos del modelo de defectos$
<*A Resu#en
Se *an presentado una serie de *iptesis acerca de problemas potenciales en
software basado en componentes , un modelo que clasifica posibles orgenes
.sea por equi+ocacin o intencionales/- defectos en la aplicacin , fallas
obser+ables$ Los criterios que se presentan cubren +arios puntos de +ista sobre
los mismos problemas , ser+irn de base para preparar criterios de prueba , una
estrategia general$ !or el momento- son elementos iniciales- que debern
completarse , +alidarse en la prctica- conforme se gane e0periencia en el
desarrollo de S%C$ Sin embargo- como este tipo de software a)n est en proceso
de consolidacin- *abr de pasar tiempo antes que *a,a e0periencia sustancial-
;D;
por lo cual estos a+ances a,udan a ir organiando la b)squeda , a ganar
e0periencia organiadamente- de modo que lo aprendido se asocie con una marca
de referencia$
(l modelo presentado es un aporte original- ,a que *asta la fec*a no se conoce un
esfuero seme1ante$ 4dems- debe recordarse que- a)n para software tradicional
, orientado a ob1etos- no e0iste a)n un modelo completo- lo cual da un +alor
especial a estos aportes$
(l modelo propuesto .ms all de los lmites de este traba1o/ tiene importancia- al
menos- en tres aplicaciones#
i$ !re+encin de defectos$
ii$ !reparacin de pruebas$
iii$ Depuracin de S%C$
4dems el modelo a,uda a profundiar en los fundamentos de las aplicaciones
basadas en componentes , resulta una gua )til en el estudio de los di+ersos
elementos que forman una plataforma para S%C$
;D&
Ca!0tu)" A Cas"s de !rueba de
integracin
3no de los propsitos del presente traba1o es la deri+acin de pruebas de
integracin a partir de la descripcin arquitectnica- que se realia seg)n lo tratado
en el captulo <$ La preparacin de pruebas tiene el respaldo del modelo de
defectos +isto en el captulo B$
3sualmente las pruebas se concretan en casos de prueba que se generan en
con1untos .suites/$ Cada caso de prueba contiene- al menos- un con1unto de datos
de entrada- la salida esperada , las condiciones de e1ecucin$ De 2stos el primero
condiciona las otras dos- , es al que nos referiremos principalmente$
Dada la estructura de una aplicacin de software basado en componentes- las
pruebas deben ser funcionales$ Dentro de 2stas la que parece con+enir es la
prueba por particin en dominios- generando casos tpicos para cada uno de ellos$
(n este captulo se discuten di+ersas formas de acoplamiento entre componentes-
la generacin de dominios , el m2todo combinatorio bsico- la con+ersin de otras
formas de acoplamiento a una donde se pueda aplicar el m2todo bsico , la
generacin de casos de prueba propiamente dic*os$
Se complementa con una lista de casos pendientes$
;D<
A*4 M1t"d"s de &eri$icacin a !artir de )a ar3uitectura
(n la +erificacin esttica se busca identificar posibles problemas desde antes de
desplegar una aplicacin- pero cuando ,a se *an elegido los componentes ,
conectores que se utiliarn$ 4dems de identificar problemas puede ser una
a,uda para preparar me1or los modelos de aplicaciones , contribuir a asegurar la
calidad de la aplicacin$
La +erificacin esttica puede aplicarse a toda una aplicacin o a subcon1untos
cone0os de 2sta$ La e0igencia de cone0in se debe a que no tiene sentido probar
interaccin de partes desconectadas$
4lgunas +erificaciones necesarias son#
o conecti+idad completa
o compatibilidad de instancias de componente con los tipos
o compatibilidad de conector , componentes de la aplicacin con los tipos
o compatibilidad de interacciones de la aplicacin con las de los conectores
tipo
o a+isos de concurrencia
4 continuacin se describe cmo realiar cada una de estas +erificaciones- pero
antes se presentan algunas definiciones que se emplearn ms adelante$
4.1.1 &efiniciones
Las definiciones que siguen emplean elementos definidos en el lengua1e 4rquipp-
que se present en el captulo <$
C"#!atibi)idad de )0neas$ Dos lneas- lin , linN- son compatibles- denotado por
Compatible.lin-linN/- si los atributos que definen la lnea son iguales o parte de una
1erarqua en el caso del tipo de datos$
Compatible.lin- linN/ si
papel.lin/ Q papel.linN/
.tipoHdatos.lin/ Q tipoHdatos.linN/
tipoHdatos.lin/ es especialiacin de tipoHdatos.linN/ /
Cardina)idad de un e)e#ent"# n)mero o pare1a de n)meros separados por dos
puntos sucesi+os- en notacin de 3ML$
Card.elem/ Q c o bien Card.elem/ Q a$$b
La segunda forma indica que son aceptables +alores en el inter+alo ?a-bA$
CardMin.elem/ se define como la cardinalidad mnima de una lnea dada$ Si
Card.elem/ Q a$$b- entonces CarMin.lin/ Q aI si Card.elem/ Q c- entonces
CardMin.lin/ Q c$
;DB
Todo enlace tiene dos lneas que corresponden a los e0tremos del mismo$ 3n
enlace e podr escribirse como e Q .l'- l;/ donde l' , l; son las lneas que forman
el enlace$
4.1.2 Conectivia completa.
4 partir del diagrama topolgico;< de una aplicacin se puede determinar si la
conecti+idad est completa$ !ara que lo sea debe cumplirse#
i$ todo componente del modelo est conectado al menos con un
componente diferente de s mismo
ii$ todo conector incluido en el modelo est conectado en sus dos
e0tremos$
4.1.( Compatibilia e componentes.
La compatibilidad entre una instancia de componente , su tipo se +erifica entre las
descripciones contenidas en la aplicacin , las que se tengan de tipos
predefinidos$ La liga entre ambas se realia a tra+2s del diagrama de 1erarqua-
que relaciona componentes a tra+2s de *erencia$ Los tipos bsicos seran- en
principio- los de la plataforma Ja+a- de los cuales deri+aran componentes
especficos para funciones determinadas , de a* componentes ms especficos
de una implementacin dada$
Los puertos , sus lneas en un componente particular- correspondiente a una
implementacin dada- deben corresponder e0actamente con aquellos que definen
el componente gen2rico$
Los puertos , lneas de un componente que *ereda de uno o ms deben ser
compatibles- ba1o los criterios siguientes#
o los puertos , lneas obligatorios deben *eredarse como talesI
o los puertos o lneas opcionales pueden o no ser *eredadosI
o puertos adicionales en el componente descendiente son aceptables
Lo anterior se puede e0presar as#
Si C5 es una instancia de componente de tipo CT- donde el tipo asume toda la
1erarqua que le antecede en forma plana-
sea Li el con1unto de lneas del componente C5 en forma puerto$lnea ,
sea Lt el con1unto de lneas del componente CT
entonces- para que C5 sea compatible con CT debe cumplirse que
a$ l Lt tal que CardMin.l/ f ' lN Li tal que Compatible.l- lN/
b$ l Lt tal que Cardinalidad.l/ Q '$$;- entonces si lN Li
Compatible.l- lN/;B
;< Descrito en Captulo < dentro de la definicin de 4rquipp$
;B (ste caso corresponde a lneas opcionalesI solo se analian si e0isten$
;D>
4.1.) Compatibilia e conectores
Los conectores- en general- se tomarn de los e0istentes- por lo cual no se *ece
necesaria una +erificacin particular como en el caso de componentesI si no fuera
el caso- suponiendo U5 instancia de conector , UT tipo de conector- debe
cumplirse que
i$ todo enlace e0istente en UT debe e0istir en U5
ii$ cada lnea de cada enlace de UT debe ser compatible con la lnea
correspondiente en el enlace equi+alente en U5$
!or otra parte- el conector tiene- en su definicin- roles predefinidos para los
componentes que conectar$ (stos roles se e0presan en sus enlaces , lneas- que
deben coincidir con las empleadas en la aplicacin$
4 partir del diagrama topolgico se identifican segmentos constituidos por un
conector , un par de componentes por 2l ligados- sea U el conector- Lc cualquiera
de los componentes ligados por U- entonces
i$ para cada enlace e Q .l'- l;/ en U- l' , l; estn ambas conectadas o
ninguna lo est-
ii$ si l Yl'- l;Z conectada con lN- lN Lc Compatible.l- lN/
4.1.4 Compatibilia e interacciones
Las interacciones de cada par de componentes a tra+2s de un conector .para
todos los conectores in+olucrados/ deben ser compatibles con la interaccin que
caracteria al conector tipo$ !ara +erificarlo se parte de#
o diagramas de interaccin del conector
o diagramas de interaccin del segmento analiado en la aplicacin
Las +erificaciones que se deben *acer son las siguientes#
o Mensa6es e8istentes# todo mensa1e en la interaccin de la aplicacin debe
tener un equi+alente en alguna de las interacciones del conector
o Orden es!erad"# el orden parcial de los mensa1es de la interaccin de la
aplicacin debe ser un subcon1unto del orden parcial de las interacciones
del conector
o Mensa6es "b)igat"ri"s# todo mensa1e obligatorio en la interaccin del
conector debe e0istir en la interaccin de la aplicacin
Debe notarse que las interacciones pueden ser m)ltiples , todas ellas deben
satisfacer los criterios anteriores$ 4dems- la forma de e0presar las interacciones
puede +ariar en grado de detalle- lo cual debe ser tomado en cuenta al *acer las
comparaciones$
4.1.5 Avisos e conc"rrencia
@o toda la concurrencia que se presenta en un sistema es e+idente en todo
momento , con+iene ad+ertir dnde ocurre- para pre+enir problemas$ (sta
+erificacin puede *acerse como sigue#
;DD
(0istir concurrencia en una aplicacin si se cumple alguna de estas condiciones#
a/ C componente de la aplicacin , U conector unido a C tales que
Cardinalidad.C7/ f ;- donde C7 es el con1unto de componentes de la
aplicacin ligados con C a tra+2s de UI
b/ C , CN componentes de la aplicacin , U conector uniendo ambos , CN se
despliega en ms de un equipo
(n ambos casos *abr un componente en un e0tremo de un conector , un
con1unto en el otro- con acti+idad concurrente ;>$ (sta situacin introduce
acoplamientos adicionales , puede originar agotamiento de recursos , otros
problemas$ (l a+iso permite que el desarrollador sea conciente de la e0istencia de
tales elementos , tome precauciones$
A*5 -"r#as de ac"!)a#ient" entre c"#!"nentes
!ara fines de prueba se pueden utiliar diferentes tipos de particin del modelo
completo$ (n este traba1o se dar preferencia a un enfoque centrado en los casos
de uso , los escenarios asociados con ellos$ Sin embargo- sea 2sta u otra la
manera de subdi+idir una aplicacin- se llegar a bloques mnimos con dos o unos
pocos componentes$ (stos bloques representan componentes ligados por
conectores- pero que corresponden a relaciones ms gen2ricas$
La manera en que se relacionan los componentes determina la manera en que
ocurre su acoplamiento- lo cual influ,e en los problemas que pueden ocurrir en su
interaccin$ !or ello- el anlisis de di+ersas formas de acoplamiento entre
componentes es un requisito para el procedimiento de prueba$
(n esta seccin se re+isarn las formas tpicas de interaccin entre componentes
, luego se agregarn consideraciones acerca del estado , de la posible
concurrencia entre componentes$
4.2.1 Acoplamiento
La forma de acoplamiento ms com)n es una relacin de agregacin- permanente
o temporal- entre un componente , otro .+er Figura >$;/
(sta relacin- que se puede representar usando 3ML- ocurre en muc*os casos-
como entre un (J% , otro- entre un browser , un ser+let , entre un cliente , un
ob1eto remoto$ !uede ser ms o menos permanente- como al incluir un plug6in-
pero en general ser temporal- como al abrir un arc*i+o o al obtener un pro0, de
un ob1eto remoto$ (n casi todos los casos- ambos componentes e0isten por s
mismos , a +eces operan concurrentemente$
;> (s decir- el inicio de e1ecucin de uno ocurre entre el inicio , fin de otro.s/$
;DE
C1
C&
Figura >$; 9elacin de agregacin
(sta relacin puede darse entre ms componentes- en forma lineal .+er Figura >$&
a/ o ramificada .Figura >$& b/$ Tambi2n puede darse concurrencia .Figura >$& c/ ,
ocurrir ciclos .Figura >$& d/$
4 % C
.4/ Lineal
4 %
C
4 %
C
.%/ 9amificada
.C/ Concurrente
4 %
.D/ Ciclo
Figura >$& 4gregacin entre ms de dos componentes
La forma ramificada puede descomponerse en cuatro casos#
a/ Se!arab)es# las funciones de las ramas son independientes ms all del
componente donde se separan
b/ Unidas# las funciones de ambas ramas se emplean en forma con1unta-
pero no dependen una de la otra
c/ C"#!uestas# la accin de una rama depende de las acciones pre+ias
en la otraI se puede +er como que una de ellas +a Kdespu2sL de la otra
d/ Si#u)t,neas# ambas ramas interact)an simultneamente- la interaccin
en una rama influ,e sobre la otra , +ice+ersaI as- resultan inseparables
4dems de la relacin de agregacin- se puede tener un tipo de relacin
asncrona- como la que ocurre en el caso de e+entos entre Ja+a%eans$ (n este
caso ambos componentes e0isten por s mismos , se comunican en ambas
;D=
direcciones$ (sta relacin puede ser sencilla o puede darse concurrencia- lo cual
complica su anlisis$
4l igual que los casos mostrados en la Figura >$&- los de relacin asncrona
pueden reducirse- parcialmente- a un caso de agregacin ms aspectos
especiales$
Tabla >$; Diferentes formas de acoplamiento entre componentes
ti!" b,sic" $"r#a genera) cas" acci"nes
Sencilla ninguna Lineal
M)ltiple e0tender
Separables separar
3nidas e0tender
Compuestas e0tender 9amificada
Simultneas m2todo
adicional h
@o recursi+o e0tender
Ciclo 9ecursi+o m2todo
adicional h
4gregacin
Concurrente m2todo
adicional h
Simple m2todo
adicional h
4sncrona
Concurrente m2todo
adicional h
h 2stos casos quedarn pendientes por a*ora$
(n la tabla >$; se muestra un resumen de los diferentes casos presentados$ La
primera columna indica si se trata de agregacin o interaccin asncronaI la
segunda especifica la forma general- correspondiente a las mencionadas un poco
antesI la tercera particularia los casos posibles$ Se inclu,e una columna que
indica las acciones que sern necesarias para su mane1o antes de sugerir
pruebas$ Las acciones inclu,en# ninguna- si la estructura se de1a tal cual-
e0tensin- que representa una e0tensin al caso de agregacin sencilla-
separacin- que implica alguna transformacin en los componentes , sus
conectores , la de m2todo adicional- que supone una parte de agregacin , otra
particular- seg)n el caso$ Los detalles se tratarn en la seccin >$>- despu2s de
detallar el modelo bsico de prueba$
4.2.2 Consieraciones acerca el estao
Los componentes- en su ma,ora- mantienen un estado mientras dura su
e1ecucin- , a +eces ms all- debido a los mecanismos de reuso$ (l estado puede
originar que cambie el resultado de una operacin dada- seg)n el estado en que
se encontraba el componente$ Sin embargo- el estado- caracteriado usualmente
;D:
por un con1unto de +alores de las propiedades del componente- difcilmente es
accesible al desarrollador$
(l funcionamiento de un componente puede presuponer la e0istencia de estado-
a)n cuando se careca de informacin acerca de cuntos , cules son los
posibles +alores que toma$ (ste sera un caso esperable$
!or otra parte- algunos componentes pueden poseer un estado inesperado-
debido a los mecanismos de reuso o a la deserialiacin de componentes
en+iados a almacenamiento permanente .aunque 2stos no sean aceptados como
componentes por algunos in+estigadores/$
3n caso ms comple1o de estado es el que ocurre por la interaccin de di+ersos
componentes con alguna forma de concurrencia- que tal +e no se tom en cuenta
en forma debida$
(n los casos de estado inesperado- ,a sea por reuso o por concurrencia- se puede
reducir el problema si el desarrollador de componentes pre+2 tales problemas , se
asegura de no confiar en el estado que supone e0iste$ Sin embargo- el probador-
especialmente en la etapa de integracin- no puede dar por garantiado que el
desarrollador lo tom en cuenta$
(n el software orientado a ob1etos se conoce el problema del estado , *a, +arias
formas de tratarlo- aunque casi siempre suponiendo el acceso al cdigo fuente$
Los modelos de mquinas de estados son una *erramienta )til en tales casos$
4dicionalmente- a)n cuando se tenga una clase encapsulada- e0isten maneras de
acceder a algunas +ariables de estado- por e1emplo con clases nue+as que
acceden a +ariables en modo protegido$
(n el software basado en componentes no se tiene acceso al cdigo fuente ,
qui ni a los modelos a que responde la implementacin de un componente$ (sto
introduce serios problemas$
Los modelos de estados pueden prepararse de acuerdo a la especificacin del
software o bien a partir de la implementacin$ La primera opcin siempre es
riesgosa- porque no cubre las modificaciones realiadas en implementacin ,
puede quedar obsoleta rpidamente$ La segunda requiere acceso a la
implementacin$ !or la naturalea de los componentes- los modelos tendrn que
ser creados a partir de las especificaciones de lo que se espera *aga el
componente- ms que de lo que afirma su creador$ (sta forma de modelar puede
resultar riesgosa- pero es lo ms que se puede lograr- a menos que el
desarrollador del componente conceda al desarrollador acceso al cdigo de
aplicaciones .por pertenecer a una misma empresa o por acuerdos/$
(l estado puede incluir aspectos relacionados con los recursos de que dispone un
componente$ !or e1emplo- la memoria disponible- puede +ariar dinmicamente ,
;E'
cambiar los lmites de accin de un componente que mane1a cantidades +ariables
de datos$
@o todas las operaciones ofrecidas por un componente dependen del estadoI por
e1emplo las de tipo informati+o , aquellas que regresan un resultado que
)nicamente depende de los parmetros de entrada- no sufren por cambios de
estado$ Las dems son moti+o de preocupacin$
4dems de conocer los estados posibles- si se debe considerarlos en las pruebas
debe e0istir acceso a las +ariables que los definen$ (ste *ec*o no siempre es
posible$ (n el caso de Ja+a &- se promue+e la e0istencia de funciones que
informen el estado de las +ariables pri+adas- pero no es una poltica obligatoria ni
e0isten mecanismos para reforarla- por lo cual no se puede contar con ellas$
!ara modelar los estados no basta el acceso a las +ariables que lo definen- sino
conocer sus dominios , clases de equi+alencia- lo cual puede ser
insuficientemente conocido- a)n por el desarrollador$
(n caso que el estado- o al menos parte del mismo- no sea accesible- debern
utiliarse m2todos indirectos- como podran ser#
o generar pruebas de estados m)ltiples entre estados distinguibles a partir de
salidas
o forar serialiacin peridica del componente para analiar el estado
KcongeladoL$ (sto slo es posible para componentes serialiables , puede
resultar complicado por los m2todos de proteccin +a ofuscamiento del
cdigo Ja+a$
o modelar estados supuestos dada la semntica conocida del componente
(n este traba1o se considera de e0trema importancia el problema del estado- pero
no se ofrece una solucin- al menos por el momento$ Lo ms sern algunas
sugerencias en la seccin >$B- basadas en la recomendacin general de modelar
los estados a partir de las especificaciones , tomando en cuenta los tipos de
conector empleado , las sugerencias de estado que estos inclu,an$
4.2.( Consieraciones acerca e la conc"rrencia
La concurrencia se presenta en casi todas las aplicaciones de S%C$ (n el caso de
la !lataforma Ja+a- se tiene- por e1emplo- entre Ja+a%eans conectados por
e+entos- con ob1etos 9M5 , entre (J%$ La concurrencia puede ocurrir#
o dentro de un proceso- a ni+el de *ilos
o entre procesos residentes en un mismo equipo
o entre procesos residentes en diferentes equipos
La concurrencia se manifiesta- en forma mu, general- cuando el inicio de un *ilo o
proceso ocurre entre el inicio , el fin de otro$
La concurrencia acarrea diferentes problemas como#
;E;
o acceso m)ltiple a un recurso .componente- dispositi+o/- tra,endo como
consecuencia su agotamiento o falta de disponibilidad
o uso compartido de +ariables- que puede originar resultados inesperados o
que +aran de una e1ecucin a otra
o p2rdida o duplicacin de mensa1es cuando e0iste proceso asincrnico
(stos problemas obligan a considerar aspectos tales como la sincroniacin de
acceso a regiones crticas- que lle+a a generar acoplamientos a +eces
inesperados- entre los componentes in+olucrados$
Dentro de la plataforma Ja+a & e0isten mecanismos para resol+er algunos de
estos problemas .por e1emplo la instruccin Ksynchroni1e2 para e+itar colisiones
entre *ilos de un proceso/- pero no se les refuera- por lo cual quedan su1etos a la
disciplina del programador$ !ara fines de prueba no se puede garantiar que se
emplearon tales mecanismos$
Ftros mecanismos- )tiles para (J% de entidad- son las transacciones$ 3na
transaccin es una secuencia de operaciones que tiene dos )nicas alternati+as# se
e1ecuta completamente o no se e1ecuta en absoluto$ Ja+a ofrece mecanismo de
mane1o de transacciones con di+ersas opciones de implementacin$ (n este caso-
nue+amente- *abr que asegurarse que se emplean adecuadamente$
Ftra forma de concurrencia que aparece en sistemas como los de S%C es la
e0istencia de clientes m)ltiples para un solo ser+idor- como pueden ser diferentes
llamadas desde browsers$ (sto puede traer otras consecuencias- como el
agotamiento de recursos .por e1emplo el lote de ser+lets o de (J% reutiliables
disponibles/ , repercutir- por lo menos- en el rendimiento del sistema , en su
posible bloqueo en casos e0tremos$
4unque la concurrencia es un aspecto mu, importante del S%C- por el momento
no se *a profundiado acerca de su prueba- para la que e0isten pocos
antecedentes$ (n este traba1o no se tratar en detalle- ms all de sugerencias
especficas a casos particulares$
A*: Generacin de d"#ini"s ( estad"s a !artir de escenari"s
(n esta seccin se discute la definicin de los diferentes dominios , subdominios
que participan en el m2todo combinatorio , que sern empleados en la
preparacin de casos de prueba$
4.(.1 2eneracin e ominios
!ara establecer el dominio completo de un componente se proceder en partesI
primero se muestra el dominio para una funcin- luego para el componente- sin
considerar el estado , por )ltimo considerando el estado$
;E&
4l considerar las funciones que ofrece un componente debe tenerse en cuenta
que usualmente se usa un enfoque de ob1etos en su implementacin .es el caso
particular de la plataforma Ja+a/ , entonces los componentes aparecen como
clases- que *eredan de otras clases e implementan algunas interfaces$ 4s mismo-
requieren de una serie de ser+icios de clases que contienen- correspondientes a
otros componentes- de 4!5s de ser+icios de terceros o al ambiente donde residen
, operan$ Las funciones o ser+icios ofrecidos por el componente sern la
combinacin de todos los que ofrece su propia interfa ms las de las que *ereda
o implementa .+er Figura >$</$
Los elementos correspondientes a lo que ofrece el componente pueden
descubrirse empleando el mecanismo de introspeccin- al menos en sus aspectos
sintcticos , considerando los problemas semnticos ,a tratados anteriormente$
!ara determinar los ser+icios necesarios no *a, un mecanismo equi+alente- por lo
que tendr que confiarse en la documentacin$ !ueden estar incluidos en el
mismo arc*i+o J49 del componente- en otro arc*i+o J49 o en arc*i+os
independientes$
@)cleo del componente#
Funciones propias
Funciones *eredadas
(lementos que se
requiere incluir
Figura >$< !artes de un componente$
Conociendo los ser+icios ofrecidos , sus parmetros se pueden determinar los
dominios de entrada que resultan de inter2s para las pruebas$ !ara *acerlo
con+iene partir de la definicin de los tipos de los parmetros , de las
precondiciones incluidas en las reglas asociadas con los propios ser+icios- de
acuerdo a la e0tensin a 3ML propuesta en el captulo <$
!ara una funcin dada- fi- el dominio de datos se puede obtener de las
combinaciones de parmetros- como#
Dfi Q YfiZ 1Q'- $$$- n YDp1 Z
;E<
donde Dp1 corresponde al dominio del parmetro 1$ (l +aco se agrega para el caso
de que accidentalmente se omita el parmetro- caso que debe considerarse como
posible$
(l dominio de todo el componente 4- sin considerar el estado- se obtendr de la
unin de todas sus funciones#
D4 Q i Q;-$$$-m Dfi
Si se considera el estado- se obtiene el con1unto de estados- (S- , entonces se
tendr una nue+a e0presin que resulta del producto de los estados posibles por
el dominio antes obtenido#
DS4 Q D4 (S
4*ora bien- tal dominio resulta mu, e0tenso , es mu, probable que contenga
infinidad de elementos irrele+antes$ 4s pues- *abra que reducirlo a un alcance
ms prctico$ 3na parte que probablemente pueda ser reducida sin problemas es
la que corresponde a elementos *eredados- que probablemente no se emplearn
e0plcitamente , que- en todo caso- su prueba corresponde a pruebas de unidad$
(n este traba1o se *a considerado como gua la descripcin arquitectnica- por lo
cual se propone reducir los dominios a aquellos elementos que pueden ocurrir en
la aplicacin ba1o estudio$ (stos elementos se caracterian como aquellos cu,a
funcin aparece en alg)n mensa1e contenido en al menos un escenario de
cualquiera de los casos de uso correspondientes al subsistema ba1o prueba ,
donde se emplea el componente$ !odra formaliarse como#
DE4 Q iQ;-$$$-m YDfi ] fi aparece en al menos un escenario de
al menos un caso de uso del subsistema en prueba Z
Claramente se tiene que DE4 D4$
(n forma similar se puede agregar el estado obteniendo DS(4$
(n el caso del estado no es necesario reducir el dominio- ,a que corresponde a un
modelo creado por el desarrollador- que incluir )nicamente los estados
rele+antes$ La generacin de estados se trata en la subseccin siguiente$
4.(.2 2eneracin e estaos
La generacin de estados depender de la calidad de la descripcin de la
aplicacin , los tipos de componentes de que se disponga$ 4)n cuando *ace falta
;EB
ms traba1o a este aspecto- se presentan tres casos- uno bsico , dos adicionales
que pueden a,udar a definir los estados e0istentes- para fines de prueba$
Caso bsico#
a/ para un componente de datos se consideran los estados Yine0istente-
+aco- lleno al m0imo- lleno a un +alor medio- tipo de datos equi+ocadoZ
que cubren lo mnimo- sin ma,or informacin$
b/ para un componente de entidad .proceso/# estados de la mquina de
estados del tipo bsico del componente 3nin Yine0istente- +ersin
equi+ocadaZ
Caso de interacciones#
si +arios mensa1es incidentes en un componente tienen una relacin de
orden e0plcita- indican que e0iste un cambio de estadoI siguiendo el grafo
de orden parcial se pueden estimar los estados +isibles e0ternamente- a)n
sin determinar los +alores internos$ (ste m2todo puede generar estados de
ms e ignorar otros que no aparecan e0plcitamente- pero es una
apro0imacin posible
Caso de reglas#
si se cuenta con reglas pero no un modelo de estados- se puede crear una
apro0imacin pero queda en manos del desarrollador$
A*< M1t"d" c"#binat"ri" b,sic"
La relacin de agregacin entre dos componentes es la ms sencilla de tratar , se
le pueden aplicar los criterios de ?9osenblum- ;::=A discutidos en el captulo &-
con algunas adaptaciones$ Se tratar primero la forma general , luego se
agregar el estado$
4.).1 ,arte general
Se denotar por D[ el dominio de entrada de un componente [ formado como
sigue#
Los miembros de D[ son datos de la forma ?$uncin9 !ar,#etr"s@$ Tales datos
se pueden pensar como un solo m2todo de in+ocacin que contiene informacin
acerca de la funcin especfica a acti+ar , los parmetros que le correspondan$
4*ora bien- en el caso de los componentes no se emplea necesariamente todo el
dominio- por lo cual con+iene definir un subdominio
DE[ Q Y 0 ] 0 D[ , 0 aparece en alg)n escenario de alg)n caso de usoZ
Cuando interact)an dos componentes la relacin entre los dominios de entrada de
ambas queda como sigue .+er Figura >$B/# Desde el punto de +ista del
componente 4 los miembros de su dominio de entrada .D(4/ se pueden agrupar
;E>
en dos subdominios# aquellos que- al e1ecutarse 4- originan llamadas a %- es decir
Klo atra+iesanL , aquello que no interact)an con %$ Se llamar atra&iesaE+?DEA@
al primero , e&itaE+?DEA@ al segundo$
D(4
D(%
Componente
4
Componente
%
4tra+iesa6%.D(4/
(+ita6%.D(4/
9ele+ante6para64.D(%/
5rrele+ante6para64.D(%/
Figura >$B Subdominios rele+antes en la interaccin entre componentes$
!or otra parte- desde el punto de +ista de %- su dominio de entrada .D(%/ se
puede subdi+idir en dos# el que agrupa +alores que pueden originarse desde
llamadas del componente 4 , aquellos que noI estos correspondern a acciones
que se in+ocarn desde otros componentes o en otras aplicaciones$ 4l primero se
le llamar re)e&anteG!araGA?DE+@ , al segundo irre)e&anteG!araGA?DE+@$
Las definiciones formales de los cuatro subdominios se muestran aba1o#
atra&iesaE+ ?DEA@ H I8 DEA J su e6ecucin de A c"n &a)"r 8 atra&iesa +K
e&itaE+?DEA@ H DEA L atra&iesaE+?DEA@
re)e&anteE!araEA?DE+@ H I 8 DE+ J 8M atra&iesaE+?DEA@ (
e6ecucin de A c"n &a)"r 8M atra&iesa + c"n un &a)"r 8K
irre)e&anteE!araEA?DE+@ H DE+ N re)e&anteE!araEA?DE+@
La seleccin de tales subdominios permiten proponer asegurar que se satisfagan
las necesidades de prueba del componente en relacin con su conte0to , del
conte0to en relacin con el componente$
Siguiendo el enfoque de dominios- para un programa .!/ se considera adecuado
un con1unto de pruebas donde se e1ercitan todos los subdominios rele+antes del
dominio de entrada .D!/$ Tales subdominios se determinan de acuerdo a alg)n
criterio que separa los +alores en clases con un mismo tipo de respuesta$ (l
con1unto de subdominios rele+antes ba1o un criterio U se denota como SDU.D!/$
(n el caso de componentes- considerando dos de ellos que interact)an .4 , %/- el
componente % ser probado por un con1unto de pruebas T%I si se le estu+iera
probando en forma aislada- T% debiera ser adecuado para todo el dominio de
;ED
entrada de %$ Como se le probar )nicamente en relacin con 4- entonces T%
deber ser adecuado para el subdominio Re)e&anteG!araGA?DE+@I esto se
e0presa como#
Pruebas de "!erabi)idad ?unidad@;
3n con1unto de pruebas T% es adecuado6para64 seg)n U si e0iste al menos
un caso de prueba para cada subcon1unto en SDU.rele+ante6para64.DE%//
donde SDU.`/ representa los subdominios rele+antes de ` ba1o el criterio U
(n forma similar- si se desea probar 4 en relacin con %- T4 no necesita ser
adecuado para todo el dominio de entrada de 4- sino )nicamente para el
subdominio de +alores que interact)an con %- es decir Atra&iesaE+?DEA@I se
e0presa como#
Pruebas de integracin;
3n con1unto T4 de pruebas es adecuado6en % seg)n U si atra+iesa cada
subcon1unto en SDU. rele+ante6para64.DE%//$
SDU.rele+ante6para64.DE%// Q YD rele+ante6para64.DE%/ ] DN SDU.DE4/ , D
DN , DN ^ D irrele+ante6para64.DE%/ , D Z
4.).2 *9tensin para consierar estao
(n muc*os casos los componentes presentan estado- como se discuti
anteriormente$ !or a*ora se supondr que se conocen los posibles estados , se
desea considerarlos en la generacin de pruebas$ !ara ello se puede proceder
como se muestra en la Figura >$>- tomando los +alores que representan cada
estado como parte de las entradas$ 4s- los elementos del dominio de entrada se
caracteriarn como
?$uncin9 !ar,#etr"s9 estad"@
(l nue+o estado generado por la e1ecucin de una entrada sera parte de la salida$
Las otras consideraciones sobre subdominios permanecen sin cambio$
4.).( *9tensin a n componentes
4)n cuando no se esperan colecciones mu, largas de componentes- s pueden
ocurrir grupos de ms de dos- por lo que con+iene e0tender el modelo bsico- con
o sin estado- para el caso de n componentes con relacin de agregacin$ (sta
e0tensin es congruente con la consideracin de que un componente puede estar
constituido por otros menores o que una combinacin de componentes da origen a
un componente ma,or$
;EE
618579
6.8=575 15C-75
Figura >$> (stado como parte de la entrada$
Como paso intermedio- consideraremos el caso de tres componentes- como se
muestra en la Figura >$D$
C % 4
Figura >$D Caso de tres componentes
(n este caso se tiene que deben considerarse las interacciones entre 4 , %- en la
forma descrita anteriormente- ,- adems- las interacciones de los tres
componentes a partir de estmulos de entrada al componente 4 , que generan
acciones en % que- a su +e- inician acti+idades en C$ @o es necesario considerar
el caso de interaccin de % con C ,a que la estructura no de1a independencia a %$
La interaccin de los tres componentes se puede describir aplicando dos +eces los
raonamientos de dos componentes- es decir- interesan +alores del dominio de 4
que atra+iesan % , atra+iesan C- as como +alores del dominio de C que son
rele+antes para % , para 4- es decir que pro+ienen de +alores de % que a su +e
pro+ienen de +alores de 4$ La e0pansin quedar as#
atra&iesaEC ?DEA@ H I8 atra&iesaE+?DEA@ J 8M atra&iesaEC?DE+@ ( )a
e6ecucin de A c"n &a)"r 8 atra&iesa + c"n &a)"r 8MK
e&itaEC?DEA@ H DEA E atra&iesaEC?DEA@
re)e&anteE!araEA?DEC@ H I 8 re)e&anteE!ara +?DEC@ J
8M atra&iesaE+?DEA@ ( e6ecucin de A c"n &a)"r 8M atra&iesa + c"n un &a)"r
8K
irre)e&anteE!araEA?DE+@ H DE+ E re)e&anteE!araEA?DE+@
De a*- usando el mismo raonamiento en forma encadenada- se puede
generaliar una relacin recurrente como sigue- reemplaando los nombres de los
componentes por C;- C&- $$$- Cn$
atra&iesaECi ?DEC4@ H I8 DEC4 J )a e6ecucin de C4 c"n &a)"r 8 genera
in&"cacin de C5 c"n &a)"r 8M ( 8M atra&iesa Ci?DEC5@K
;E=
e&itaECi?DEC4@ H DEC4 L atra&iesaECi?DEC4@
re)e&anteE!araEC4?DECi@ H I 8 DECi J
8M atra&iesaECi?DECiE4@ ( 8M re)e&anteE!araEC4?DECiE4@K
irre)e&anteE!araEC4?DECiE4@ H DECiE4 E re)e&anteE!araEC4?DECiE4@
Las condiciones de adecuacin se pueden escribir#
3n con1unto de pruebas TCi es adecuado6para6C; seg)n U si e0iste al menos un
caso de prueba para cada subcon1unto en SDU.rele+ante6para6C;.DECi//
!ruebas de integracin#
3n con1unto TC; de pruebas es adecuado6en6Ci seg)n U si atra+iesa cada
subcon1unto en SDU. rele+ante6para6C;.DECi//$
SDU.rele+ante6para6C;.DECi// Q YD rele+ante6para6C;.DECi/ ]
DN SDU.DEC;/ , D DN , DN ^ D irrele+ante6para6C;.DECi/ , D Z
A*A C"n&ersin de "tras $"r#as de ac"!)a#ient"
(n la seccin >$& se mencionaron di+ersos casos de relacin entre componentes ,
se indicaron algunas acciones para adecuarlas al modelo bsico combinatorio$ (n
esta seccin se describen las adecuaciones necesarias- caso por caso$
4.4.1 Agregacin simple + mAltiple
La agregacin simple , la m)ltiple- sin ramas- corresponden a lo descrito en la
seccin anterior- quedando pendiente la generacin especfica de dominios-
estados , casos de prueba- que se tratarn en la seccin siguiente$
4.4.2 Agregacin ramificaa
La agregacin ramificada- con sus cuatro casos- obliga a un tratamiento
cuidadoso- ,a que algunos pueden reducirse a otros ms simples$ Los cuatro
corresponden a la situacin presentada en la Figura >$E$
;E:
4 %
C
Figura >$E 4gregacin ramificada
A*A*5*4 Se!arab)e
(n el caso separable se presenta cuando el componente 4 interact)a con % o con
C- pero su resultado depende slo de uno de ellos- seg)n el +alor con que se
e1ecuta 4$ (sta situacin se presenta cuando un componente- seg)n el +alor que
tiene en un momento- selecciona un componente u otro- por e1emplo dos plug6ins
diferentes o dos arc*i+os diferentes$
Claramente- este caso permite separar las pruebas en dos cadenas# 4 con % , 4
con C$ 4 cada una de ellas se le aplica lo +isto en la seccin >$B- sin necesidad de
adaptaciones$
A*A*5*5 Unidas
(ste caso se presenta cuando 4 in+oca funciones de % , de C pero sin que
importe el orden- es decir- lo que recibe de % o C no influ,e sobre la consulta del
otro$ Solamente 4 ser responsable de combinar los resultados$ (sta situacin se
presenta cuando un componente emplea dos au0iliares en sus tareas- donde cada
uno aporta algo para la solucin- pero sin ser consciente de la e0istencia del otro$
!or e1emplo ocurre cuando se consultan dos fuentes de datos .arc*i+os- orculos-
etc$/$
(ste caso puede +erse- para fines de pruebas- como la cone0in de 4 con una
sola componente cu,o dominio resulta de la unin de los dominios de % , C- como
se muestra en la Figura >$=
4 % C
Figura >$= 9esultado de combinar % , C para ramificacin unida
(n este caso- para aplicar lo +isto en la seccin >$B bastar definir#
D(%C Q D(% D(C
\ a este nue+o dominio se le aplicarn los desarrollos de la seccin >$B$
;='
A*A*5*: C"#!uestas
(sta situacin se presenta cuando la interaccin de 4 con % modifica los +alores
con que debe acceder a C .o +ice+ersa/$ (sta situacin puede modelarse como
que C depende de %- ms que directamente de 4$ 4s pues- se puede con+ertir en
un caso lineal m)ltiple 4 con % , % con C- al menos para fines de prueba$ 3na +e
realiada esa con+ersin- se puede proceder a probar seg)n los principios de la
seccin >$>$
A*A*5*< Si#u)t,neas
(ste )ltimo caso representa interacciones de un componente con dos en forma
simultnea- interacti+a$ !uede +erse como un caso de concurrencia- aunque
diferente de la que se presenta ms adelante$ !or el momento no se tratar$
4.4.( Agregacin con ciclos
(s mu, posible que la agregacin de origen a ciclosI por e1emplo- cuando se
presenta el uso de callbac7 en ob1etos remotos +a 9M5$ (sta situacin-
simplificada en la Figura >$:- puede darse en ciclos ms largos- in+olucrando ms
componentes$
% 4
Figura >$: 4coplamiento con ciclos
(n caso de e0istir ciclos- con+iene distinguir dos casos# el recursi+o , el simple$ (n
el segundo el componente % recibe una interaccin de 4 , a su +e inicia otra en
4- pero 2sta no lle+a a nue+as in+ocaciones de %$ (n cambio el caso recursi+o s
genera nue+as in+ocaciones a %$ (l caso recursi+o no se tratar por a*ora$
(l caso sencillo puede tratarse de la siguiente manera# como la segunda
acti+acin de 4 no in+olucra interaccin con %- puede crearse un componente
+irtual 4N con un subcon1unto de funciones de 4 tales que no generan
interacciones con %$ La situacin quedar como en la Figura >$;'$
!ara aplicar lo +isto en la seccin >$B- se define#
DE4N Q Y0 e+ita6%.DE4/Z
4N % 4
Figura >$;' 9uptura de ciclo
;=;
4.4.) Agregacin conc"rrente
La agregacin concurrente ocurre cuando dos o ms componentes *acen uso de
los ser+icios de un mismo componente- tal como en muc*os casos clienteser+idor$
Fcurre- por e1emplo- en in+ocacin a (J% , en ob1etos remotos +a 9M5-
seg)n se muestra en la Figura >$;;$
(sta situacin debe e0aminarse cuidadosamente para determinar si la
concurrencia produce acoplamiento entre 4 , C- +a %$ Si se puede asegurar que
no ocurre- se puede separar en dos casos# 4 con % , C con %- aplicndose lo +isto
en >$B$ (sto podra ocurrir cuando se usan (J% sin estado o ser+lets donde se
asegura no *aber estado$
C
% 4
Figura >$;; 4gregacin concurrente
(l caso donde s *a, acoplamiento entre 4 , C no se trata por a*ora$
!osiblemente se puede refle1ar el acoplamiento en el estado de % , mane1arlo de
esa maneraI en ese caso se podr separar en dos casos 4 , % por un lado , C , %
por otro- donde se consideren casos de di+ersos estados posibles debido al otro
componente$
4.4.4 Asociacin asncrona
Ftro tipo de asociacin entre componentes es el de tipo asncrono- que ocurre
cuando la interaccin se da entre componentes que no detienen su e1ecucin para
atender al otro$ (sta situacin se presenta- por e1emplo- en el caso de e+entos
entre Ja+a%eans$
(0isten dos casos a considerar# el de asociacin sencilla , el caso concurrente-
por e1emplo cuando *a, acoplamiento entre componentes receptores de e+entos-
+a estado del emisor , la opcin de +eto e0istente en Ja+a &$ (l caso de
concurrencia no se tratar por a*ora$
!ara tratar el caso sencillo se le puede separar en dos partes- ambas necesarias#
un modelado combinatorio para asegurar la funcionalidad- seguido de
aseguramiento de propiedades asncronas$ La primera parte es similar a la tratada
en la seccin >$B$
;=&
La parte adicional- dedicada a los aspectos de asincrona concentra los problemas
en el receptor- que puede +erse incapa de responder adecuadamente a los
estmulos$ Tpicamente se mostrara como p2rdida de e+entos o duplicacin de
datos de alguno de ellos$ Ja+a & inclu,e mecanismos para e+itar la ocurrencia de
tales problemas- pero no tiene manera de reforar su utiliacinI de *ec*o es lo
que se probara$
(l funcionamiento de esta parte de pruebas se presenta as# se crea un dri+er que
manipule al receptor de e+entos , se prueba su funcionamiento *asta los lmites
que se desea- para asegurar que no e0iste p2rdida o duplicacin de e+entos o
alteracin del estado- si es accesible$ (l dri+er puede *acer uso de e+entos
pre+iamente capturados , retransmitirlos a diferentes +elocidades- *aciendo uso
de facilidades para el mane1o de *ilos$
A*B Cas"s de !rueba
La generacin de casos de prueba puede organiarse en tres etapas#
a/ 5dentificar los subdominios atra+iesa6Ci , rele+ante6para6C1
b/ Seleccionar un criterio que determine los subdominios de inter2s
c/ Generar los casos de prueba
4.5.1 /"bominios atraviesa + relevante
(stos dos subdominios se definieron con anterioridad , resultan importantes para
determinar la adecuacin de las pruebas realiadas$ La definicin ideal de tales
subdominios se realia a partir de las especificaciones de los componentes$ (n
caso de no contarse con informacin suficiente se puede usar como gua la
descripcin arquitectnica$
Si se utilia la descripcin arquitectnica- los subdominios de inter2s se tendran
que obtener de los diagramas de interaccin ,- de e0istir- las reglas que definen el
funcionamiento de los componentes$ Los escenarios indican al menos las
operaciones que se relacionan- aunque no dan informacin acerca de la relacin
de +alores de parmetros de entrada a un componente , de in+ocacin del
siguiente$ (ste )ltimo aspecto se deber obtener del funcionamiento del
componente o de1ar los subdominios abiertos- lo cual redundar en una amplitud
innecesaria$
4.5.2 Criterio para eterminar s"bominios e inter7s
Las estrategias de prueba de comportamiento- como las que se *an propuesto
para componentes- particionan los dominios de entrada en clases de equi+alencia
ba1o alg)n criterio$ De ese modo- basta con seleccionar casos de prueba que
representen a todas las clases de equi+alencia para tener confiana en el
funcionamiento del componente$
@ue+amente lo ideal es contar con informacin precisa a partir de las
especificaciones- con lo cual se crea la particin adecuada$
;=<
Como no siempre se puede asegurar que e0istir tal informacin- se puede
apro0imar al menos un poco para reducir los casos de prueba- aunque no dar la
misma confiana en los resultados .que de todas formas sern me1or que no tener
nada/$
(l procedimiento de emergencia ser el siguiente#
;$ 4 priori# se pueden suponer dos clases de equi+alencia#
a/ datos in+lidos
b/ datos +lidos
Si un dato se caracteria como .fi- p;- p&- $$$- pn- e7/- donde fi es una funcin- e7
un estado , p;- $$$- pn los +alores de los parmetros- entonces
3n dato es in+lido si ocurre al menos una de estas condiciones#
i$ la funcin no e0iste
ii$ alguno de los parmetros que debe tener +alor est +aco
iii$ alguno de los parmetros tiene un +alor de tipo inapropiado
i+$ el estado no e0iste o en ese estado no se puede aplicar la funcin
Debe aclararse que el tipo de dato inapropiado puede no ser e+idente- ,a que
entra en 1uego la *erenciaI si un dato corresponde a un subtipo registrado- ser
aceptable sintcticamente- pero puede ser inapropiado por su semntica$ De
*ec*o es un defecto obser+ado en la prctica$
Los datos que no caen en ninguna de las situaciones anteriores sern +lidos$
Debe obser+arse que el subdominio de datos in+lido es de gran importancia para
re+isar las respuestas correspondientes a +alidacin- e0cepciones , otros
problemas que pueden da"ar un sistema al tiempo de e1ecucin$
&$ Los dos con1untos anteriores pueden refinarse , subdi+idirse si se obser+an
mensa1es condicionales o reglas que in+olucren una condicin$ Cada condicin
parte en dos- potencialmente- alguno de los subcon1untos ,a obtenidos$
4.:.( 2eneracin e casos e pr"eba
(l )ltimo caso corresponde a seleccionar casos de prueba para cada subdominio
de inter2s$ (sta parte puede *acerse de dos maneras#
o un +alor al aar
o +alores tpicos , a la frontera
(n principio ambas formas son igualmente buenas , la segunda est contenida en
la primera$ Sin embargo- la e0periencia de los probadores de software indica que
muc*os problemas ocurren con +alores fronterios- por lo que la segunda forma es
ms propicia para identificar defectos$
;=B
(n tipos de datos tradicionales es relati+amente fcil establecer +alores a la
frontera .por e1emplo el entero de +alor absoluto ms peque"o- el ms grande
positi+o- el menor negati+o- etc$ Sin embargo en tipos de datos ms elaborados-
no siempre es tan claro$ Depender del usuario el definir tales +alores$
3n traba1o donde se aplic un m2todo automtico a la generacin de datos de
prueba en Ja+a%eans es el de ?8elasco- &'';A- orientado a pruebas de unidad$
Los casos de prueba deben tener una forma de calificar el resultado esperado$ (n
el caso de los datos in+lidos- el resultado cae en una de estas categoras#
o &a)"r errne"# el resultado- aunque del tipo esperado- difiere en su
+alor
o resu)tad" ines!erad"# en +e del resultado esperado se produce otra
accin .o falta de ella/I por e1emplo- en +e de un +alor num2rico
aparece una cuerda de caracteres
o #ensa6e de err"r# ocurre una situacin que no se deseaba pero se
consideraba posible , en +e del resultado esperado aparece un
mensa1e de error
o e8ce!cin# ocurre una situacin que no se esperaba
De 2stas- la primera , la tercera indican un problema mane1ado por el software ,
las otras dos resultados inaceptables$
Los casos +lidos son un poco ms comple1os- ,a que el criterio de aceptacin
puede ser difcil de formular .por e1emplo si se espera un n)mero primo de &'
cifras- o la identificacin de un punto irrele+ante en un mapa/ requiriendo un
orculo que puede ser el desarrollador o un usuario e0perimentado$
A*F Cas"s !endientes
!or el momento se tienen pendientes los casos relacionados con problemas de
concurrencia ,- *asta cierto punto- la obtencin de un con1unto de estados para
me1orar las posibles pruebas$ Concretamente se tienen pendientes#
o ramificaciones simultneas en el caso de agregacin
o concurrencia en agregacin
o concurrencia en asociacin asncrona
4dems se puede me1orar el caso de sincroniacin para la asociacin asncrona
sencilla$
A*O Pruebas n" $unci"na)es
Todo lo tratado anteriormente se refiere a pruebas funcionales- que son la base
mnima para que el sistema opere$ Sin embargo- e0isten otras que
tradicionalmente se *an llamado Kno funcionalesL- entre las cuales se inclu,en
seguridad- robuste , rendimiento$
;=>
!or el momento se tratar el caso de la robuste$
4.;.1 1ob"stez
(l concepto de robuste se asocia a un funcionamiento aceptable de un elemento
o sistema a)n en presencia de situaciones o datos inesperados$ (1emplos de tales
situaciones son# datos fuera de los dominios para los que fue definido un
componente- ocurrencia de e0cepciones- fallas ocasionales en el contenedor- falla
en el sistema de red , falla del *ardware$
4nte un e+ento inesperado- un software robusto debe poder seguir operando o
bien sufrir una degradacin graciosa- es decir- reducir sus capacidades o
respaldar lo posible antes de cerrarse .caso e0tremo/$
(n sistemas monolticos lo ms posible es que un e+ento inesperado origine la
falla total del sistema$ (n sistemas distribuidos- en cambio- es posible considerar
que los componentes no afectados puedan seguir traba1ando- a)n con capacidad
reducida- , a)n reconfigurarse con componentes de emergencia$
Sin entrar a las muc*as posibilidades que e0isten para la robuste-
consideraremos tres casos solamente#
o mane1o de e0cepciones
o resistencia del sistema ante fallas en un componente o conector
o falla del *ardware o la red
4.;.2 Manejo e e9cepciones
Las e0cepciones que pueden ocurrir a un componente pueden considerarse en
dos grupos# las asociadas con los ser+icios ofrecidos o recibidos , sus
parmetros- que en general son pre+isibles- al menos como una posibilidad- , por
otro lado las e0cepciones correspondientes al funcionamiento de la
implementacin del componente$
Desde el punto de +ista de prueba no se puede suponer que el desarrollador del
componente *a,a pre+isto las e0cepciones de ninguno de los dos grupos$
Dado el refuero a los tipos de datos que mane1a la plataforma Ja+a- es fcil
preparar una lista de e0cepciones posibles relacionadas con las interfaces ,
generar casos de prueba que obliguen su ocurrencia$
Las e0cepciones que no corresponden a interfaces se de1an pendientes por a*ora$
4.;.( ?allas e "n componente o "n conector
Como se di1o en el captulo B- es mu, posible que un componente presente
algunas fallas que no se consideren crticas , que- en ausencia de alternati+as-
*agan que se le integre a pesar de ellas$
;=D
4parte de ese caso- puede suceder que un componente sufre una falla que no
*aba aparecido en pruebas anteriores$ iCmo determinar el efecto de esa falla
sobre otros componentesS
3n caso relacionado es el de una falla en un conector .o contenedor/$ Tal falla-
para el componente destinatario de la comunicacin- puede ser indistinguible de
una falla en el componente correspondiente$
(sta situacin puede modelarse como en la Figura >$;&- donde se muestra como
un ruido introducido bien sea en un componente C;- bien sea en el conector que
afectan a un componente C&$
!ara tratar estos casos se recomienda seguir el m2todo de in,eccin de defectos
propuesto por ?8oas- ;::= bA , descrito en el captulo &- pero ampliado a tipos de
datos no elementales$ !ara *acer esto se deben mane1ar instancias de datos
errneas pero del tipo correcto , tambi2n instancias de datos seme1antes al
correcto .por medio de *erencia/$ (n general no es de esperar que ocurran
cambios ms dramticos en este ni+el- ,a que lo impide la propia plataforma Ja+a$
Figura >$;& Comunicacin con fallas
(l criterio de adecuacin depender del grado de robuste deseado$ Si no importa-
se *ace innecesario por completo$ !or otra parte- es difcil establecer un lmite
superior- ,a que las posibilidades de +ariacin de un con1unto finito de datos
pueden ser infinitas- al menos en su sentido prctico$
4.;.) ?allas e 0ar#are + re
Las fallas de *ardware .locales o de red/ as como elementos de software que
soportan comunicacin- son mu, posibles , afectan a un sistema distribuido$ Tales
fallas pueden ser momentneas o permanentes$ (n el primer caso- el software
debe poder sobre+i+ir- restaurando su funcionamiento en un estado confiable$ (n
el segundo- por lo menos debiera proteger la parte sobre+i+iente de su estado
para una recuperacin posterior
(stas pruebas pueden realiarse aplicando fallas reales .apagando dispositi+os o
terminando procesos/ , analiando el comportamiento de los componentes
C; C&
ruido ruido
;=E
afectados- suponiendo que ,a se *aban probado anteriormente en sus aspectos
funcionales$
Ftra posibilidad es la simulacin de fallas$ !ara esto puede *acerse como en el
caso de la seccin anterior- in,ectando defectos al sistema- pero de efectos
ma,ores- que correspondan a una falla del tipo que se est considerando$
A*P Resu#en
(n este captulo se *an descrito modelos combinatorio , de estados para S%C-
sobre los cuales se preparan criterios adecuados de prueba$ Tambi2n se usan de
gua en la preparacin de casos de prueba$
(n el captulo se trataron con ms detalle los casos de pruebas operacionales , de
interoperacin para modelo combinatorio , de estados- de1ando pendiente la
consideracin de concurrencia$ Se precis especialmente la manera de preparar
casos de prueba para el caso combinatorio- que- aunque insuficiente- es una parte
necesaria .indispensable/ de la prueba de software$
Tambi2n se trataron pruebas no funcionales- para la cual se mostraron +arios
casos$
(n este captulo el aporte principal est en el anlisis de las di+ersas formas de
acoplamiento entre componentes- necesario para preparar pruebas relacionadas
con la interaccin entre componentes$ (ste anlisis permiti e0tender la propuesta
de 9osenblum ?9osenblum ;::EA- quien slo consider dos componentes en
relacin de agregacin$
(l anlisis de diferentes acoplamientos est basado en la arquitectura del sistema-
del cual se debern re+isar las relaciones entre componentes- a partir del
diagrama topolgico , de los diagramas de secuencia correspondientes a los
casos de uso$
_ste captulo toma su +erdadera dimensin en con1uncin con el siguiente- donde
se podr apreciar me1or la liga con la parte arquitectnica , con el modelo de
defectos$ Sin embargo- puede decirse que las pruebas de tipo combinatorio son
)tiles para descubrir un gran n)mero de defectos de interaccin de los tratados en
el captulo B$ 9efiri2ndose a la Tabla B .tipos de defectos/- las pruebas
combinatorias son )tiles para identificar la ma,ora de las diferentes categoras de
defectos- con las siguientes e0cepciones# no son de utilidad para las funciones
duplicadas , los defectos de concurrencia , resultan insuficientes en casos como
cdigo adicional- sincrona , comunicacin con el usuario$
!or otra parte- los elementos de +erificacin del modelo que se tratan en la
seccin >$; a,udan a identificar- antes de las pruebas- problemas de protocolo en
la interaccin entre componentes$ 4dems- al asegurar la +alide del modelo se
;==
obliga al desarrollador a refle0ionar acerca de su sistema- lo que redundar en
menor n)mero de defectos deri+ados de +ersiones inadecuadas$
;=:
Ca!0tu)" B Estrategia de !rueba de
integracin*
(n los captulos anteriores se *a detallado un modelo de fallas , formas de
generar casos de prueba de integracin para software basado en componentes$
Jace falta a*ora dise"ar una estrategia general de prueba de integracin que
unifique lo anterior de modo co*erente , susceptible de automatiacin$
(n este captulo se bosque1a una estrategia posible- ateni2ndose a la naturalea
de los componentes , los elementos analiados en captulos anteriores$
5nicialmente se presenta una serie de consideraciones generales- a continuacin
se muestra la estrategia general , luego se particularian +arias de sus etapas que
inclu,en pruebas funcionales , no funcionales$
;:'
B*4 C"nsideraci"nes genera)es
!ara establecer una estrategia de prueba *ace falta precisar una serie de
elementos que influirn en ella$ (n esta seccin se presentan algunos de los ms
importantes$
5.1.1 Cone9in con los moelos ar!"itectnico + e efectos
4l preparar las pruebas de integracin consideramos su liga con elementos
presentados anteriormente$ (n especial se apo,an en el modelado arquitectnico
.+er Captulo </ , el modelo de defectos .+er Captulo B/$
Las pruebas podran prepararse sin ninguna base- pero en ese caso seran
pruebas ocasionales sobre la e1ecucin del sistema- sin gua especfica$ 4l
momento de ocurrir una falla- se tendra que localiar , corregir por prueba , error-
lo cual resulta mu, costoso , poco fiable$
Si se cuenta con un modelo arquitectnico- se usa 2ste como gua para preparar
pruebas- en forma general- suponiendo que cualquier cosa puede fallar en
cualquier caso$
Cuando se tiene un modelo de defectos- se tiene una gua sobre elementos que
pueden fallar , en qu2 circunstancias$ 4s se pueden preparar pruebas especficas
para los elementos ms susceptibles de falla$ 4dems- cuando ocurre
efecti+amente una falla- se tiene una gua para localiarla , corregirla$
La combinacin de modelado arquitectnico , uso de un modelo de defectos
permite preparar pruebas de acuerdo con la estructura de la aplicacin , con el
conocimiento de los problemas potenciales- dirigiendo los esfueros para que
resulten ms efecti+os$
4s- la estrategia que se presenta en este captulo descansa en el estilo de
modelado arquitectnico presentado en el Captulo < , considerando el modelo de
defectos descrito en el Captulo B$ (n +arios puntos de este captulo se precisarn
algunas cone0iones$
5.1.2 C"no aplicar pr"ebas e integracin
Dada la naturalea del software basado en componentes .S%C/ se tiene que las
pruebas de integracin no ocurren en un )nico momento$ De *ec*o e0isten tres
tiempos de aplicarlas# el primero- cuando se est ensamblando una aplicacin- el
segundo al tiempo de despliegue , el tercero en mantenimiento$
(n la etapa de preparacin se seleccionan , ensamblan componentes$ !or su
naturalea- el ambiente de traba1o es diferente del definiti+o- ,a que se requieren
cargas , descargas de contenedores- software de apo,o , componentes- que
seran inaceptables en un ambiente operati+o de empresa$ (n esta etapa las
;:;
pruebas de integracin a,udan a asegurarse de la compatibilidad de componentes
, su buena e1ecucin con1unta$
3na +e que se tiene una aplicacin- o parte de la misma- debe desplegarse en su
ambiente operati+o normal$ Dado que este ambiente puede tener diferencias con
el ambiente de desarrollo- debe probarse nue+amente la buena operacin de los
di+ersas componentes$ (s posible que incluso algunos elementos modificables en
las componentes deban a1ustarse en este momento$
!or )ltimo- en su +ida normal- la aplicacin requerir mantenimiento-
principalmente por reemplao de +ersiones de alguno.s/ de sus componentes o de
los contenedores$ 4 este ni+el las pruebas pueden considerarse de regresin- pero
por su naturalea siguen siendo de integracin$
Cualquiera que sea el momento- la estrategia general que se delinea en las
secciones siguientes es aplicable- con los a1ustes adecuados$ !or e1emplo- en el
caso de mantenimiento )nicamente ser necesario comprobar las partes del
sistema relacionadas con el componente modificado$ 4l tiempo de despliegue
*abrn de probarse las instrucciones de despliegue contenidas en los descriptores
de los componentes$
5.1.( Coniciones especiales el /BC
(n general- una aplicacin basada en componentes ser un con1unto de pieas de
software e1ecutndose en +arios equipos , organiadas en +arios ni+eles .tiers/$
!ara fines de pruebas- se contar con una descripcin arquitectnica de la
aplicacin- as como descripciones generales de los conectores a emplear
.especialmente contenedores/- basadas en los elementos presentados en el
captulo <$
!or la naturalea del S%C las pruebas no pueden contar con acceso al cdigo
fuente , qui ni a descripcin de los componentes en t2rminos de reglas como
las descritas en el captulo <$ !or ello- la estrategia de pruebas cae dentro de las
estrategias basadas en el comportamiento- llamadas tambi2n funcionales o de
ca1a negra$
Dado que- en general- la informacin ms de fiar ser la de las interfaces , la
descripcin de interacciones- la estrategia de pruebas caer entre las de particin
de dominio- que busca probar las diferentes interacciones agrupadas en clases de
equi+alencia$
Dentro del marco anterior- se debern preparar las pruebas con la informacin
disponible- *aci2ndose notar que- a ms detalle- me1or planeacin de pruebas$
Debe *acerse *incapi2 en que la modeliacin de componentes puede caer ms
en lo que se desea de ellos , no en su implementacin efecti+a$ Sin embargo-
para fines de prueba funcionales esto es correcto- ,a que se desea +erificar que
;:&
los componentes realicen las funciones que el dise"ador *a identificado como
necesarias$ Si- adems- se cuenta con modelo de implementacin- las pruebas
sern ms pro+ec*osas$
3na )ltima consideracin es la necesidad de contar con pruebas de acti+idades
concurrentes- ,a que los S%C presentan muc*as situaciones de esta naturalea$
Dentro de este tipo de pruebas deben incluirse las relacionadas con cambios de
estado- uso compartido de recursos , sincrona$
5.1.) Criterios
3na de las preocupaciones de los desarrolladores de software es el alto costo de
las pruebas$ 4 +eces- por a*orrar- se omiten pruebas$ (n el caso del software
basado en componentes- parece *aber un consenso en que son necesarias
muc*as pruebas pero- al mismo tiempo- se da poca importancia a +alidar los
componentes indi+iduales adquiridos , su adecuada integracin$ Seg)n e0pertos
de la industria .por e1emplo ?Uoomen , !ol- ;:::A/ parte del problema reside en
una estrategia inadecuada$
3na buena estrategia debe orientarse a identificar pronto los problemas ms
gra+es ,- en general- probar lo menos que se pueda pero satisfaciendo criterios de
adecuacin$
4s pues- una caracterstica de la estrategia propuesta ser reducir pruebas
innecesarias- e+itar repeticiones , concentrarse primero en los puntos ms
rele+antes para el uso de una aplicacin dada$ (sto +a mu, de la mano con el
2nfasis que se *a dado al modelado arquitectnico que inclu,e los casos de uso
de la aplicacin$
(n la descripcin arquitectnica de las aplicaciones basadas en componentes se
present la con+eniencia de establecer un perfil de uso$ (n caso de e0istir- este
debe a,udar a orientar la estrategia *acia los aspectos ms importantes de la
misma$ (n caso de no e0istir- a)n se podr ganar algo con la descripcin de los
casos de uso de la aplicacin
4lgunos autores reducen el alcance de las pruebas de integracin- de1ando
aspectos de concurrencia , no funcionales para las pruebas de sistema$ (n
realidad- la frontera entre integracin , sistema es borrosa , en el S%C es
necesario conocer- al menos en parte- qu2 tan bien se comportan partes del
sistema frente a problemas donde son importantes la concurrencia , la robuste-
entre otros aspectos$ (sta situacin es ms e+idente cuando se trata de sistemas
distribuidos- en los que parte de las pruebas se realian por equipo- es decir sobre
subsistemas- pues en tales elementos son rele+antes .por e1emplo el posible
agotamiento de los recursos/$ (n la estrategia propuesta s se consideran los
elementos mencionados- aunque no en el inicio$
;:<
(n la estrategia que se describe en la siguiente seccin se considera que se
desean probar al menos los siguientes aspectos#
i/ operabilidad de cada componente en su ambiente
ii/ interoperacin de componentes
iii/ aspectos de concurrencia
i+/ aspectos no funcionales
B*5 Estrategia genera)
Dado que los sistemas basados en componentes son una forma de software de
gran comple1idad- aunque enmascarada por la aparente reduccin de partes- una
estrategia de prueba inclu,e distintas etapas$
La ran principal de separar en etapas el proceso de pruebas es crear
fundamentos sucesi+os que permiten probar elementos cada +e ms comple1os-
sin necesidad de regresar a aspectos ,a +erificados o +alidados$ (sta separacin
permite tambi2n fi1ar fronteras en las que se puede suspender el proceso de
prueba- en caso necesario$ !or e1emplo- si se *a llegado a prueba de operabilidad-
al menos se sabe que cada componente por separado funciona adecuadamente
en su ambienteI las fallas que puedan aparecer sern causadas por defectos en la
interaccin entre componentes$
La estrategia general que se propone comprende cuatro grandes etapas#
a/ +erificacin esttica
b/ pruebas de operabilidad
c/ pruebas de interoperacin- que comprenden#
i$ pruebas funcionales
ii$ prueba de robuste
iii$ pruebas de concurrencia
d/ otras pruebas
La +erificacin esttica corresponder bsicamente al ni+el de descripcin
arquitectnica , se orienta a identificar incompatibilidades antes a)n de ensamblar
componentes$
Las pruebas de operabilidad se orientan a asegurar que cada componente
funcione correctamente en su ambiente de despliegue$
Las pruebas de interaccin son las principales en integracin$ Se les separa en
tres por la diferencia de su naturalea# funcionales- de robuste , de concurrencia$
Las pruebas funcionales se orientan a los ser+icios que el sistema ofrece , se
aplican bsicamente sobre las interacciones descritas en los casos de uso$ Ftros
aspectos importantes se de1an para las siguientes etapas$
;:B
Las pruebas de robuste se orientan a +erificar la resistencia del sistema ante
fallas del equipo o del software au0iliar$ !or la naturalea del S%C este problema
es mu, importante- como se *io notar en el Captulo B$
Las pruebas de concurrencia resultan importantes en sistemas distribuidos- como
lo son- en ma,or o menor medida- los basados en componentes$ 4spectos tales
como uso de recursos compartidos- problemas de acoplamiento oculto-
sincroniacin , otros- surgen por la operacin concurrente entre componentes$
(n otras pruebas se inclu,en pruebas no funcionales que inclu,en mu, di+ersos
aspectos- de los cuales- por a*ora- se considera slo la carga- que se relaciona
con la reaccin del sistema ante diferentes presiones de ser+icio$
(n la tabla D$; se presenta un resumen de la estrategia- que se ir detallando en
las secciones siguientes$
Tabla D$; (strategia general
Eta!a Subeta!a
Comparacin de descripciones
arquitectnicas
5dentificacin de posibles elementos
desprotegidos
Veri$icacin est,tica
Funciones faltantes , sobrantes
Despliegue de componentes
Funcionalidad de componentes Pruebas de "!erabi)idad
9obuste
Funcionalidad por cadenas de
interacciones
9obuste
Pruebas de inter"!eracin
Concurrencia
Otras !ruebas Carga
Las pruebas que se aplicarn corresponden- en su ma,ora- a elementos descritos
en el captulo anterior$ (n las secciones siguientes se describen un poco ms , se
re)nen en un procedimiento algortmico en la seccin D$E$
B*: Veri$icacin est,tica
(sta etapa se realiar antes de proceder a ensamblar o desplegar componentes
, cubre dos aspectos# la re+isin arquitectnica , el aseguramiento de que no
e0istan elementos desprotegidos$ 4 continuacin se describen ambos$
(l ob1eti+o de esta etapa es asegurar que realmente puede pasarse a pruebas- ,a
que el sistema propuesto cumple mnimamente con lo que se espera de 2l$
;:>
(sta etapa es congruente con las tendencias modernas de pre+enir ms que de
corregir$ La +erificacin a ni+el arquitectnico puede *acerse a)n antes de
terminarse el modelo de la aplicacin , antes de aceptar un componente
particular- por lo que puede identificar equi+ocaciones gruesas muc*o antes de
que sean gra+es$
5.(.1 1evisin ar!"itectnica
(l contar con una descripcin arquitectnica tiene- como una de sus +enta1as-
poder analiar los modelos$ (n el caso de componentes- e0isten dos grupos de
descripciones arquitectnicas# las de tipo terico- correspondientes a modelado de
aplicaciones generales- con 2nfasis en los conectores disponibles , la de la
aplicacin concreta$ (sta )ltima debe ser compatible con la primera- de modo que
cada estructura corresponda a una permitida , en especial que el uso de
conectores se realice como est prescrito$ (n general- las aplicaciones utiliarn
subcon1untos de interacciones- aunque posiblemente algunas se repitan +arias
+eces
(l ob1eti+o particular de esta etapa es asegurar la co*erencia entre los elementos
seleccionados , lo que se espera de ellos- a un ni+el alto de abstraccin$ (l
anlisis se puede realiar con una aplicacin completa o con una parte- siempre
que 2sta sea cone0a- ,a que de lo contrario una parte de la +erificacin se
desperdicia$
(l procedimiento para *acerlo se asegurar de que#
a/ e0ista conecti+idad completa
b/ *a,a compatibilidad de instancias de componente con los tipos
c/ conectores , componentes de la aplicacin sean compatibles con los
tipos
d/ e0ista compatibilidad de interacciones de la aplicacin con las de los
conectores tipo
e/ se emitan a+isos de concurrencia
Los m2todos particulares se presentaron en la seccin >$;$
5.(.2 *lementos esprotegios
La programacin concreta de componentes descansa muc*as +eces sobre
programacin orientada a ob1etos$ _sta permite de1ar desprotegidos .es decir
p)blicos/ atributos importantes de los componentes$ (sto ocurre a)n cuando el
encapsulamiento es un elemento fundamental de ese enfoque- pero que no es
reforado por los lengua1es disponibles$
Los elementos desprotegidos permiten acoplamiento entre elementos que no
debieran tenerlo$ (sta situacin- en un ambiente controlado de un solo
programador- puede a,udar a desarrollar o estudiar componentes$ !ero en un
ambiente de reuso abierto introduce inseguridad en las aplicaciones que los usan$
;:D
La situacin se agra+a por los mecanismos de e0posicin de interfa al tiempo de
e1ecucin- que permite a un componente tomar el control de otro$
4s pues- el ob1eti+o particular de esta subetapa es asegurar el encapsulamiento$
Como parte de la estrategia de pruebas de integracin se recomienda asegurarse
de que no e0isten elementos desprotegidos- o al menos conocer su e0istencia ,
los posibles riesgos que originan$ La +erificacin puede *acerse con las propias
*erramientas de desarrollo- como javap o mediante un dri+er que e0plore
interacti+amente los componentes- indagando por sus interfaces , por las
+ariables de instancia de tipo protegido , p)blico$
5.(.( ?"nciones faltantes o sobrantes
(l ob1eti+o particular de esta subetapa es asegurar que todos los ser+icios
requeridos e0istan as como la identificacin de todos aquellos innecesarios ,
repetidos$
(sta es una +erificacin que debe *acerse aunque se da por supuesta$ Como los
componentes pueden pro+enir de diferentes orgenes- resulta con+eniente
asegurarse que contenga todas las funciones que se supone inclu,en , no
contengan funciones no documentadas$ La +erificacin puede ser esttica o a
tra+2s de una *erramienta que interrogue al componente$ (sta +erificacin no
asegura que no *a,a funcionalidades ocultas de modo comple1o- pero s identifica
aquellas que cumplen con las reglas de la plataforma$
(n el caso de la !lataforma Ja+a- dado que se emplea una mquina +irtual- en
principio es posible identificar los smbolos que corresponden a m2todos$ Sin
embargo- algunas *erramientas de desarrollo con+ierten tales smbolos en otros
difciles de descifrar .ofuscamiento/I en ese caso ser ms complicada la
+erificacin$
5.(.) Bases en el moelo e efectos
Las pruebas sugeridas en esta etapa se originan en elementos presentados en el
modelo de defectos .+er Captulo B/$ (n la Tabla D$& se resumen algunas
relaciones entre dic*o modelo , las pruebas sugeridas$ La cone0in se puede
relacionar principalmente con la Tabla B$:$
B*< Pruebas de "!erabi)idad
4ntes de +alidar la interoperacin de componentes- debe asegurarse que operen
correctamente en su entorno de despliegue$ (se es el ob1eti+o de esta etapa$
;:E
Tabla D$& 9elacin entre el modelo de defectos , la +erificacin esttica
Pruebas De$ect"s !"sib)es
9e+isin arquitectnica Seleccin de componente
inadecuada
!osible concurrencia
!osible agotamiento de recursos o
e0ceso de tiempo
!roblema de protocolos ,
parmetros
(lementos desprotegidos Seleccin de componente
inadecuada
!osibles resultados inesperados
!osible malicia en desarrollo de
componente
Funciones faltantes o sobrantes Seleccin inadecuada
!osibles resultados inesperados
!osible agotamiento de recursos o
tiempo e0cesi+o
!ara la +alidacin de operabilidad se pueden sugerir pruebas a partir del diagrama
de despliegue , el topolgico$ !re+iamente se debe re+isar qu2 elementos sern
necesarios- como sigue#
a/ !ara cada equipo tpico- identificar todos los elementos necesarios#
componentes- conectores- sistema operati+o- plug*ins- etc$
b/ Si un subsistema se desplegar en uno o ms equipos especficos- debe
+erificarse cada uno de ellos con todos los elementos identificados en el
punto a$
c/ Si un subsistema se desplegar en equipos gen2ricos- deber probarse en
configuraciones esperadas .por e1emplo ba1o Cindows- ba1o 3ni0- con
ser+idor 4pac*e- etc$/
d/ Si un componente es gen2rico- debern probarse las implementaciones
que probablemente aparecern$ !or e1emplo- si un componente es
KbrowserL- sin especificacin- debern probarse los ms populares$
e/ Las pruebas especficas de cada componente deben satisfacer el criterio
de adecuacin correspondiente a los usos en que inter+endr$
3n e1emplo es el siguiente$ Suponga la configuracin dada en la Figura D$;$
!ara el equipo (;- como no se tiene ms informacin- debern considerarse
+arias configuraciones- que inclu,an los sistemas operati+os Cindows , 3ni0 , los
browsers @etscape , (0plorer
!ara el equipo (& ser necesario probar con#
a$ sistema operati+o Cindows
b$ Mquina Ja+a
c$ Mquina de Ser+lets
;:=
d$ Ser+idor 4pac*e
e$ Software de red
f$ ser+let 4LF4
(;
!lataforma6*ardware# +ariable
!lataforma 6software# +ariable
(&
!lataforma6*ardware# 5ntel
!lataforma 6software# Cindows-
4pac*e
browser
ee ser+letff
4LF4
eeconectorff
*ttp6conHser+let
g ;
Figura D$; (1emplo de despliegue$
Las pruebas que se realian en esta etapa inclu,en#
H !rueba de despliegue
H !rueba funcional usando particin de dominios
H !ruebas de robuste frente a fallas
Las pruebas de despliegue se relacionan con los elementos necesarios para que
el componente funcione- algunas +eces incluidos en descriptores de despliegue$
Tambi2n se relaciona con la inicialiacin de componentes , su localiacin- si
sern desplegados dinmicamente$
La parte funcional se relaciona con el funcionamiento del componente de acuerdo
al ambiente donde deber operar$ (stas pruebas corresponden a las que se
describieron en la seccin >$D$
Las pruebas de robuste corresponden al anlisis de la respuesta del componente
ante fallas de su ambiente$
Como en el caso de la +erificacin- estas pruebas descansan sobre los problemas
posibles sugeridos en el modelo de defectos$ (n la tabla D$< se resumen algunas
cone0iones con dic*o modelo- especialmente con+iene +er la Tabla B$:$
B*A Pruebas de inter"!eracin
3na +e asegurada la operabilidad de cada componente- o combinando las
pruebas si es ms cmodo- se procede a +erificar la interoperacin- que es el
punto central de las pruebas de integracin$
;::
Tabla D$< Cone0iones entre el modelo de defectos , pruebas operacionales
Pruebas Defectos posibles
Despliegue Documentacin
8ersin
5nicialiacin
Funcionales Documentacin
(0cepciones
Defectos originados en el
despliegue
!armetros
9obuste Mane1o de fallas
!ara describirla separaremos dos grandes casos# pruebas funcionales donde no
se presenta o no se considera la concurrencia- pruebas de robuste , pruebas
relacionadas con la concurrencia entre componentes$ (sta separacin permite
probar al menos los aspectos funcionales- a)n cuando no se pueda comprobar el
funcionamiento concurrente$
4 grandes rasgos- el procedimiento partir de los casos de usoI de los diagramas
de interaccin se particionar el sistema en cadenas de componentes que
interact)an- con+irtiendo los di+ersos modos de interaccin a formas funcionales
.+er seccin >$D/$ Sobre esas cadenas se generarn las pruebas$
Debe notarse que- al igual que en las pruebas de operabilidad- se necesita
considerar si e0isten equipos , componentes m)ltiples o gen2ricos$
5.4.1 ,r"ebas f"ncionales
Las pruebas funcionales tiene como ob1eti+o +alidar que los componentes
interaccionen adecuadamente- dentro del ambiente donde operarn- llegando a
los resultados esperados seg)n el dise"o de la aplicacin$ 4spectos adicionales-
como el funcionamiento concurrente- la robuste , la seguridad- dependen de
asegurarse que el funcionamiento bsico es correcto$
!ara las pruebas funcionales se aplicar el m2todo de particin de dominios que
se trat en las secciones >$& a >$D- aplicado a cada cadena de interaccin entre
componentes- con+ertidos a una forma compatible con la agregacin .+er seccin
>$>/$ Los detalles se tratan en la seccin D$E$
Si el encargado de pruebas de una aplicacin considera innecesario aplicar todas
las pruebas sugeridas- puede utiliar el perfil de uso de la aplicacin como gua de
la probabilidad de seleccin de una prueba dada$
(l uso del perfil ser como sigue#
&''
5.4.2 1ob"stez
4)n cuando los componentes , grupos de ellos se *a,an probado , parecan
estar bien- una aplicacin puede sufrir problemas por
a/ una falla inesperada en alguno de ellos
b/ una falla en la red
c/ una falla de *ardware
(n esos casos- un sistema comple1o- como lo ser probablemente si es S%C- no
puede simplemente fallarI debe ser capa de reaccionar de modo que se
mantenga en operacin la parte sin problemas .degradacin graciosa/ o- en el
peor caso- que se cierre adecuadamente$ La importancia de la robuste- adems
de ser un atributo general de la calidad- *a sido destacada en relacin con
componentes por 8oas ?8oas- ;::= bA , por ?Mosle,- &'''A$
(l propsito en esta subetapa ser asegurar que partes del sistema sigan
funcionando- a)n en forma disminuida- ante la ocurrencia de una falla$ 8isto de
otra forma- se busca asegurar que una componente- a)n fallando- no afecte al
resto de manera que impidan todo funcionamiento$
!ara el caso de fallas en componentes o en la comunicacin entre ellos- 8oas
propone in,ectar defectos , causar problemas en la comunicacin entre ellos- para
analiar su comportamiento ,- seg)n el caso- rec*aarlo- aceptarlo o adaptarlo$ Su
traba1o considera paso de parmetros de tipos bsicos .n)meros , cadenas de
caracteres/$
(n realidad se pasan otros muc*os tipos compuestos de datos- inclu,endo
descriptores nulos$ (stos tipos pueden ser polimrficos originando problemas
asociados con la *erencia- o pueden traer simplemente un dato errneo$ (l
problema ser ma,or cuando el ob1eto en+iado contiene informacin de control
que afectar el proceso del receptor- ,a que entonces puede iniciar toda una
secuencia de acciones impre+istas$
Los ob1etos pasados como parmetros tambi2n pueden ser compartidos- lo que
acarrea problemas potenciales- similares a los de estructuras de datos
compartidas$
(n cuanto a fallas del *ardware , la red- son tratadas por ?Mosle,- &'''A- aunque
no se dan recomendaciones precisas$
(n esta etapa se recomiendan las pruebas siguientes#
a/ alteracin de parmetros- especialmente los de control
b/ generacin de e0cepciones para analiar cmo las mane1an los
componentes
c/ generar problemas de falla de contenedor
d/ generar problemas de red .protocolo- problema de cone0in- problema
de nombres/
&';
e/ generar problemas de *ardware simulados- tales como disco
inaccesible- falta de memoria , otros$
5.4.( ,r"ebas e conc"rrencia
La concurrencia aparece entre grupos de componentes que utilian recursos
compartidos- ,a sea del sistema o a)n componentes de la aplicacin$ (n esta
etapa el ob1eti+o es asegurar que componentes cu,a funcionalidad ,a fue probada
no sufran alg)n problema deri+ado de otro componente con el cual comparten
alg)n recurso$
(n el caso de conectores tales como los contenedores de la plataforma Ja+a & se
supone que en la ma,ora de los casos el cuidado de la concurrencia est en
manos del contenedor$ !or e1emplo en caso de los (ntit, %eans$ Ftros casos
corresponden a componentes que se asignan en forma )nica- como los Stateful
Session %eans$ (n esos casos no se requieren pruebas de concurrencia- e0cepto
si se sospec*a alg)n mal funcionamiento del contenedor- pero esto se puede
analiar por separado de las aplicaciones$
(n los casos donde puede *aber concurrencia la prueba e0*austi+a de todas las
condiciones de la misma es infactible$ Como alternati+a se propone e+aluar slo
pares de interacciones que puedan representar alg)n tipo de acoplamiento$
(n efecto- para que e0ista problema entre dos o ms componentes que comparten
un tercero- debe ocurrir que el primero modifique el estado del componente
compartido de modo que el segundo componente realice una accin diferente a la
esperada- pero que 2sto no ocurra si no ocurri la primera interaccin$ (sta
+erificacin idealmente debiera realiarse estticamente- para e+itar problemas de
prueba concurrente- que son difcilmente repetibles$
!odra escribirse para representar una interaccin , su resultado#
?e9 #@ r
donde e es un estado del componente- m es una interaccin , r un resultadoI
entonces- si se cumple que
?e49 #@ r ( ?e59 #@ r
la interaccin no depende del estado- es decir- es una interaccin segura$
Si toda interaccin que in+olucra a un componente es segura- entonces el
componente es seguro para fines de concurrencia$
La concurrencia puede separarse en implcita , e0plcita$ La primera se da sin que
el desarrollador la busqueI ms bien ocurre por las caractersticas de la plataforma
empleada$
&'&
La otra forma es cuando se tienen componentes que se eligen para usarse en
forma compartida$
B*A*:*4 C"ncurrencia i#!)0cita
(ste tipo de concurrencia ocurre por los mecanismos implementados en la
plataforma$ (n el caso de Ja+a se tienen algunos casos como son#
a/ ser+lets- que reutilian elementos importantes- sin reiniciar- para ganar
tiempoI si estn bien dise"ados- su funcionamiento no debe incluir
ning)n estado- ,a que se dise"an para un uso )nico- de una in+ocacin-
proceso , respuesta$ Sin embargo- por descuido podran e0istir
elementos que mantengan un falso estado que afecte el comportamiento
posterior$
b/ %eans sin estado- que se reutilian en forma similar a los ser+lets$
B*A*:*5 C"ncurrencia e8!)0cita
(sta ocurre como parte de la solucin dise"ada por el desarrollador , no por
accidente$ (n el caso de la plataforma Ja+a se tienen +arios casos en que ocurre#
a/ uso compartido de beans de entidad
b/ uso compartido de beans de sesin
c/ uso compartido de ob1etos 9M5
d/ uso compartido de emisor de e+entos
(n los dos primeros casos se trata de aspectos controlados por los propios
contenedores- al menos si se desarrollaron adecuadamente los componentes$ 3no
de los mecanismos es el de transacciones$ (n el me1or caso *abr que probar si
tales mecanismos operan correctamente- pero puede ser necesario asegurarse
que los componentes mane1en adecuadamente la situacin$
(n el caso de ob1etos 9M5 no se cuenta con mecanismos e0plcitos , debe ser el
desarrollador quien cuide ese aspecto$
(l caso de los e+entos es importante- especialmente cuando los destinatarios de
los e+entos interrogan al emisor- a partir de la informacin recibida con el propio
e+ento$ (n esta situacin debe incluirse el mecanismo de +eto e0istente entre
receptores conectados al emisor$ (l lengua1e Ja+a tiene mecanismos para resol+er
estos problemas- pero no *a, garanta de que se utilicen correctamente$
!or el momento- a pesar de la importancia que tiene la concurrencia- no se
desarrollan m2todos de prueba especficos$
5.4.) Cone9in con el moelo e efectos
4l igual que en las etapas anteriores- con+iene relacionar los principales
problemas tratados en el modelo de defectos con las pruebas sugeridas$ 4 partir
del Captulo B , en especial de la tabla B$:- se prepar la tabla D$B donde se
resumen las principales ligas con las pruebas de interoperacin$
&'<
Tabla D$B Cone0in entre pruebas de interoperacin , modelo de defectos
Pruebas De$ect"s !"tencia)es
Funcionales Defecto lgico
(structura de datos
Lmites
(0cepciones
!armetros
Tipo de datos
!rotocolo
9obuste Mane1o de fallas
(0cepciones
Concurrencia Sincrona
!osible agotamiento de recursos
B*B Otras !ruebas
4dems de las pruebas anteriores e0isten otras asociadas a lo que se llama
Krequerimientos no funcionalesL- a)n cuando el t2rmino no sea aceptado
uni+ersalmente$ (ntre ellos se inclu,en la robuste .,a incluida en D$>$&/- la
seguridad , la carga$ (n muc*os casos tales requerimientos son su1etos de
prueba cuando se tiene completo el sistema- pero en el caso del S%C con+iene
aplicar algunas pruebas desde la etapa de integracin- ,a que el sistema puede
irse usando en prototipos sucesi+os- donde es ambiguo *ablar de sistema
completo$ !or a*ora solamente se menciona la carga$
5.5.1 Carga
(n muc*os casos los componentes operan bien cuando tienen poca carga de
datos- pero presentan problemas al traba1ar con muc*os de ellos$ Cuando e0isten
e+entos se presenta el problema de incapacidad de atender a todos los que
ocurren- en otros casos se saturan las estructuras de datos o se agota la memoria
o se satura el anc*o de banda de los conectores .especialmente de red/$
(n el caso de S%C los problemas de carga pueden surgir especialmente cuando
se da una relacin cliente6ser+idor entre pares de componentes- teniendo
m)ltiples clientes o m)ltiples ser+idores$
(n general- los autores que *an tratado este problema recomiendan ir agregando
un cliente .o ser+idor/ a la +e- de modo que se pueda determinar la carga que
resisten$
!or el momento se de1a esta recomendacin sin cambios$
&'B
La necesidad de este tipo de pruebas +iene de problemas obser+ables como los
de escalamiento , otros$
B*F Pr"cedi#ient"s resu)tantes
Los elementos de estrategia presentados en las secciones D$< a D$> se con1untan
en un procedimiento- di+idido en tres etapas$ La primera es una +erificacin
puramente topolgica$ La segunda corresponde a una etapa de anlisis , cubre el
resto de la +erificacin inicial adems de preparar los datos para la sugerencia de
pruebas de operabilidad e interoperacin$ La tercera corresponde a una sntesis
de pruebas sugeridas- correspondientes a operabilidad- interoperacin , otras
pruebas sugeridas$
5.:.1 ,arte <B verificacin topolgica
(sta parte es una +erificacin mu, general- pero que permite identificar defectos
gra+es en conecti+idad o despliegue$ 3tilia bsicamente los diagramas topolgico
, de despliegue- como se +e en el procedimiento siguiente#
(l procedimiento supone las entradas , salidas siguientes#
Entradas# diagramas de despliegue , topolgico escritos en 4rquipp
Sa)idas# lista de +erificaciones +aluadas en Ycierto- falsoZ
!rocedimiento#
3sando el diagrama topolgico#
i(s cone0oS
!ara cada conector#
iTiene componentes diferentes en sus e0tremosS
i(0iste en el diagrama de despliegue , es consistente con 2steS
!ara cada componente
i(0iste en el diagrama de despliegueS
3sando el diagrama de despliegue#
i(s cone0oS
Si *a, problemas- detenerseI en caso contrario- pasar a parte 55
5.:.2 ,arte <<B anlisis
(sta parte descansa principalmente sobre el modelado arquitectnico de la
aplicacin- e0presada en Ar!"ipp$ 4l analiar la estructura de la aplicacin se
+erifican aspectos del modelado relacionados con la +erificacin inicial , se
descompone el sistema en subsistemas para la sugerencia de pruebas de
operabilidad e interoperacin- que se generan en la segunda parte$
Entradas#
H diagrama topolgico , de despliegue
H casos de uso
&'>
H tipos predefinidos .plataforma/
Sa)idas#
para siguiente etapa#
H tabla de propiedades de componentes-
H tabla de elementos arquitectnicos por pare1as-
H lista de subsistemas-
H lista de cadenas-
H lista de interaccionesI
para desarrollador#
H a+isos de problemas$
!rocedimiento#
!ara cada caso de uso
!ara cada diagrama de secuencia
!ara cada componente
ie0iste en d$ topolgicoS
ies consistente con su tipoS
4notar genericidad- multiplicidad- sel dinmica
!ara cada par de compone ntes con interaccin
icone0in en d$ topolgicoS
consistente con d$ despliegueS
iinteracciones consistentesS
Seg)n conector actualiar multiplicidad dest$
Generar subsistemas , cadenas de interaccin
Generar lista de interacciones
4notar concurrencia potencial- acoplamientos- pruebas m)ltiples
3sando el diagrama topolgico#
iCada componente participa en al menos una interaccinS
iCada conector corresponde al menos con una interaccinS
Si e0iste alg)n problema- detenerseI en caso contrario- pasar a parte 555$
5.:.( ,arte <<$ 4l final se agregan sugerencias de pruebas adicionales-
correspondientes a +erificacin inicial- operabilidad- robuste , concurrencia$
Entradas# tablas , listas de salida de la etapa 55$
Sa)idas# casos de prueba , sugerencias de pruebas de robuste
!rocedimiento#
!ara cada subsistema
!ara cada cadena de interaccin
re+isar si es de tipo combinatorio
si no lo es- con+ertir lo posible , a+isar restante
&'D
generar dominios , estados
fragmentar de e0tremo a inicio
!ara cada fragmento
generar casos posibles .con configuracin/
Frdenar seg)n configuracin , de mnima a m0ima
(liminar repetidos
!ara cada configuracin sugerir defectos in,ectables
Sugerir pruebas generales .elem desprotegidos- funciones adicionales/
Sugerir pruebas seg)n plataforma .despliegue- acoplamientos/
Sugerir pruebas de concurrencia
5.:.) @so el proceimiento
4 continuacin se presenta el seguimiento del uso del procedimiento para el
anlisis de aplicaciones$
B*F*<*4 Siste#a de c"nsu)ta de ca)i$icaci"nes I
(l e1emplo que se analia corresponde a una +ersin mu, preliminar de la que se
present en la seccin <$D del Captulo <$ Su propsito es identificar problemas en
el anlisis de la primera parte$
Se desea un sistema de consulta de calificaciones en lnea- +a 5nternet- donde el
maestro mantiene un arc*i+o de te0to con los nombres , cla+es de sus alumnos ,
una base de datos en *o1a de clculo con las calificaciones$
Slo *a, dos funciones para el maestro# actualiar la lista , actualiar las
calificaciones$
Los alumnos tienen dos funciones# identificarse , solicitar su calificacin$
!repara
lista
Califica
maestro
alumno
(ntra
identificacin
Consulta
Figura D$& Casos de uso de la aplicacin
Se describen )nicamente dos casos de uso rele+antes para el e1emplo$
&'E
(ntra identificacin
3n alumno- usando un browser- in+oca la pantalla de login , escribe su
nombre , contrase"aI si son correctas- aparecer la pantalla de consulta$
Consulta
3n alumno desde un browser- ,a identificado- solicita una calificacin- la
cual ser e0trada de la *o1a de clculo donde reside , desplegada en el
browser$
(l diagrama topolgico de la aplicacin ser como el de la Figura D$<$
eecomponenteff
browser
eecomponenteff
login
eecomponenteff
consulta
eecomponenteff
cla+es
eecomponenteff
calificaciones
eecomponenteff
prepara
eecomponenteff
(0cel
Fperacin interacti+a
Fperaciones fuera de lnea
eeconectorff
propietario
eeconectorff
*ttp6ser+let
eeconectorff
Jdbc6odbc
eeconectorff
stream
Figura D$< Diagrama topolgico de la aplicacin
(l diagrama de despliegue se muestra en la Figura D$B$ (n 2l se muestran algunos
elementos que sern identificados en el anlisis$
&'=
alfa
login
consulta
beta
cla+es prepara
(0cel calificaciones
5ncompatibilidad entre tipo de conector , despliegue
stream
Ceb
browser
gen2rico
;$$n
4+iso de concurrencia
Figura D$B Diagrama de despliegue de la aplicacin
Los resultados de la primera etapa del anlisis quedarn como sigue#
Diagrama topolgico# icone0oS S$
Cada conector$$$
Tabla D$> 4nlisis de conectores
Conector (0iste en D$
Despliegue
3so consistente
*ttp6ser+let S S
Jdbc6odbc S S
Stream S @o
propietario S S
Conclusin# e0isten problemas , no se pasa adelante$
B*F*<*5 An,)isis de a!)icacin de e6e#!)" de) Ca!0tu)" :*
(n esta subseccin se analia la aplicacin de e1emplo presentada en el Captulo
<- en la seccin <$D$ (n la parte 5 se analia en forma globalI en las otras dos slo
la )ltima interaccin- correspondiente a la Figura <$<=- por ser la ms completa$
Se aplicarn las diferentes etapas del procedimiento a partes selectas de la
aplicacin$ @o se *ace con toda por lo repetiti+o que resultara- ,a que muc*os de
los diagramas de interaccin son similares$ Muc*os de los resultados se presentan
como tablas para ma,or claridad$
&':
4plicacin de la parte 5$
Comprobaciones#
Tabla D$D 4nlisis !arte 5
i(l diagrama topolgico es cone0oS S$
iCada conector tiene componentes distintos en sus e0tremosS S$
iCada conector en el diagrama topolgico aparece en el de
despliegue , es consistenteS
S$
iCada componente del diagrama topolgico est en el de
despliegueS
S$
i(l diagrama de despliegue es cone0oS S$
Conclusin# no *a, problemas , se puede continuar$
4plicacin de la parte 55
Se aplicar la parte 55 al diagrama de interaccin se0to .+er Figura <$<=/
Tabla D$E (lementos arquitectnicos# componentes
Componente (0iste en DT consistente genericidad multiplicidad Sel$ Din$
Ceb browser S S S @ S
Consulta S S @o ; S
Conector rmi S S @o ; @o
4ccesoHbd S S @o ; S
%ase de datos S S @F ; @o
Tabla D$= (lementos arquitectnicos# pare1as
pare1a (0iste en DT consistente 5nduce multi
Ceb browser- consulta S S S
Consulta- conector rmi S S @o
Consulta- accesoHbd S S @o
4ccesoHbd- base de datos S S @o
Subsistemas#
Yweb browser- consulta- conector6rmi- accesoHbd- base de datosZ
Cadenas#
.web browser- consulta/ ? .consulta-conector rmi/- .consulta-accesoHbd/
.accesoHbd- base de datos/ Z
Lista de interacciones .+er Tabla D$:/#
&;'
Tabla D$: 5nteracciones
iniciadora mensa1e destino
web browser 5n+oca.nombre- contra/ consulta
consulta Solicita.busca-
accesoHbd/
conector rmi
consulta DameHcalif.nombre-
contra/
accesoHbd
accesoHbd 4bre enlace base de datos
accesoHbd !ideHusuario.nombre/ base de datos
accesoHbd !ideHcalificaciones.nombr
e/
base de datos
Concurrencia potencial#
Y Ceb browser .n/- consulta.n/ Z
Y Consulta .n copias/- accesoHbd.;/ Z
4plicacin de la parte 555
!ara cada subsistema .es )nico/
La cadena de interaccin tiene un nodo con dos ramas# consulta$
Se puede separar en dos cadenas#
.web browser- consulta/ .consulta- conector rmi/
.web browser- consulta/ .consulta- accesoHbd/ .accesoHbd- base de datos/
Cada cadena es de tipo combinatorio$
Dominios , estados
Tabla D$;' 9esumen de dominios , estados
componente dominios estados
Consulta Carga inicial
5n+oca.+aco- +aco/
5n+oca.+aco- inaceptable/
5n+oca.+aci- aceptable/
5n+oca.inaceptable- +aco/
5n+oca.inaceptable- inaceptable/
5n+oca.inaceptable- aceptable/
5n+oca.aceptable- +aco/
5n+oca.aceptable- inaceptable/
5n+oca.aceptable- aceptable/
4usente
9ecursos agotados
!resente , accesible
Conector rmi Solicita.busca- 4ccesoHbd/ Conector no instalado
Conector instalado
&;;
componente dominios estados
4ccesoHbd DameHcalif.+aco- +aco/
DameHcalif.+aco- inaceptable/
DameHcalif.+aci- aceptable/
DameHcalif.inaceptable- +aco/
DameHcalif.inaceptable- inaceptable/
DameHcalif.inaceptable- aceptable/
DameHcalif.aceptable- +aco/
DameHcalif.aceptable- inaceptable/
DameHcalif.aceptable- aceptable/
!resente 9egistrado ante
rmi
!resente @o registrado
ante rmi
4usente 9egistrado ante
rmi
4usente @o registrado
ante rmi
%ase de datos 4bre enlace 5ne0istente
@o accesible
%ase de datos !ideHusuario.+aco/
!ideHusuario.inaceptable/
!ideHusuario.aceptable/
!ideHcalificaciones.+aco/
!ideHcalificaciones.inaceptable/
!ideHcalificaciones.aceptable/
4ccesible
@o accesible
Casos
Los casos no se detallanI corresponden al producto cartesiano de los dominios ,
los estados de la tabla anterior$
9obuste
5n,ectar defecto en#
equipo;- en equipo&- en red- en browser- en consulta- en accesoHbd- en
conector rmi- en base de datos- en conector *ttp6con6ser+let
B*O Resu#en
Se *a descrito una estrategia de prueba de integracin para software basado en
componentes que inclu,e di+ersos tipos de pruebas , +erificaciones$ Las pruebas
inclu,en aspectos estticos , dinmicosI 2stos )ltimos de tipo operacional de cada
componente , de interoperacin$ La interaccin se analia con pruebas
funcionales , no funcionales$
La estrategia se concret en un procedimiento di+idido en tres etapas$ (l
procedimiento en su con1unto es original , no se conoce de algo similar para
componentes en la literatura actual$ Sin embargo- algunas partes del mismo se
fundamentan en m2todos establecidos- como se indic donde corresponde$
&;&
La estrategia propuesta descansa en los elementos desarrollados en captulos
anteriores- especialmente el modelo de defectos , la generacin de casos de
prueba- como se mostr en di+ersos puntos del captulo$
!ara +alidar la estrategia propuesta a)n *ace falta realiar e0perimentos de
prueba para afinar las pruebas propuestas- alterar su orden o reemplaar las que
no proceden$
&;<
C"nc)usi"nes
4l concluirse este traba1o se puede afirmar que se *an logrado las metas
consiguiendo aspectos originales en algunos puntos e inno+adores en otros- a)n
cuando no sean totalmente originales$ (n particular- para las metas se tiene#
a/ !roponer un lengua1e descripti+o de arquitectura orientado a software basado
en componentes , )til para pruebas$
(l lengua1e se *a definido , se *a comenado a emplear$ Ja resultado )til
para el modelado de aplicaciones de tama"o reducido$ (n traba1os futuros
*abr de probarse en aplicaciones ma,ores$
b/ !roponer un modelo de defectos para el software basado en componentes$
(l modelo se *a completado- cubriendo las tres etapas relacionadas con los
defectos# su causa- el defecto en s , su consecuencia probable$ Dada la
poca e0periencia que e0iste en desarrollo de este tipo de software- la ma,or
parte corresponden a defectos deri+ados de la naturalea del S%C- con
algunos aspectos probados e0perimentalmente$ 4 futuro *abrn de
obser+arse otros sistemas reales para depurar , ampliar el modelo- pero la
estructura actual representa un buen marco de referencia para continuarlo$
c/ (stablecer m2todo.s/ para deri+ar pruebas de integracin especficas a partir de
la descripcin arquitectnica de una aplicacin dadaI las pruebas estarn
fundadas sobre el modelo de defectos$
Se *an propuesto +arios m2todos de deri+acin de pruebas a partir de la
descripcin arquitectnica- inclu,endo la +erificacin inicial- m2todos para
&;B
+alidar la operabilidad , la interoperabilidad$ ùeda pendiente- para otro
traba1o- lo relacionado con pruebas de concurrencia$
d/ !roponer una estrategia de prueba- con base en la descripcin arquitectnica ,
la naturalea del S%CI la estrategia re)ne las sugerencias de la meta anterior$
La estrategia se propuso- empleando elementos arquitectnicos ,
elementos deri+ados de la naturalea del S%C , la manera de desarrollarlo$
(sta estrategia se *a ensa,ado en aplicaciones peque"as$
e/ (stablecer caractersticas bsicas que debe satisfacer un componente$ La lista
debe ser de utilidad en la planeacin de pruebas$
(sta meta- de +alor mu, secundario- pero importante como piea cla+e para
el desarrollo del traba1o- se *a logrado- al menos mientras se logra ma,or
difusin al S%C$ Los resultados se presentan en el captulo tres$
(n el a+ance de las metas anteriores se *an ganado algunos aspectos
adicionales- de los cuales se pueden destacar#
a/ dado que el tema de S%C est en sus inicios- al igual que muc*os aspectos
de arquitectura de software- el desarrollo de este traba1o *a debido a+anar
en diferentes frentes- relacionados unos con la clarificacin de la naturalea
del S%C- de su relacin con los modelos arquitectnicos , de 2stos con las
pruebas$ Todo este desarrollo- un poco circular- *a contribuido a aclarar los
di+ersos aspectos , su interrelacin$ (sta claridad *ubiera sido un buen
punto de partida para el rpido a+ance del traba1o de tesis- aunque no era
posible en el estado del arte de tales temas al tiempo de iniciarse$
b/ la e0tensin a 3ML que se desarroll como parte de la relacin entre
modelos arquitectnicos , generacin de pruebas- promete poder utiliarse
a un ni+el inferior- en la integracin de componentes a partir de elementos
ms simples como clases indi+iduales- lo cual representara una a,uda
adicional para la prueba de integracin de software orientado a ob1etos-
tema que tambi2n es deficiente en la actualidad$
!or otra parte- se *an encontrado di+ersos lmites que no eran e+identes al inicio
del traba1o$ Dos de ellos son#
a/ los elementos de modelado de estados para comportamiento no detallado
de componentes , sus interacciones son reducidos por a*oraI esta
limitacin surge por la falta de informacin interna de los componentes- que
resulta in*erente a su naturalea
b/ el modelado de concurrencia entre componentes- que representa un
aspecto de enorme importancia en este tipo de software- por el momento no
se *a podido atacar por falta de modelos adecuados
&;>
Como traba1o futuro se considera- en una primera etapa#
a/ Desarrollar una *erramienta que automatice- al menos parcialmente- la
aplicacin de la estrategia propuesta$ Tal *erramienta recibira
descripciones de aplicaciones en formato te0tual o las obtendra de salidas
de *erramientas e0istentes;D$
b/ 4plicar tanto el modelado como la estrategia de preparacin de pruebas en
un ambiente de empresa$ (sto podra obligar a considerar otras
plataformas- como las mencionadas en el Captulo ;$
La combinacin de los aspectos anteriores permitir refinar el lengua1e 4rquipp ,
la estrategia propuesta- a la +e que se enriquece el modelo de defectos$
Ftro traba1o futuro- de gran importancia , de tipo ms formales el considerar los
aspectos de concurrencia- que son ine+itables en gran parte del S%C$ (n este
aspecto se pueden relacionar las propuestas de este traba1o con los desarrollos de
otros in+estigadores que se concentran en modelos deri+ados de mquinas de
estados$
4dems de los aportes ligados al logro de las metas- el presente traba1o *a
generado una serie de presentaciones en congresos , algunas publicaciones- as
como un traba1o de tesis de maestra$ La ma,ora fueron citados en las
introducciones de los diferentes captulos , la tesis corresponde a ?8elasco- &'';A$
;D !or e1emplo 9ational 9ose .+er *ttp#VVwww$rational$com/
&;D
Re$erencias +ib)i"gr,$icas
&;E
4
4dler- 9$M$ ;::># aEmerging standards for component softwarea$ 5((( Computer-
&=#<- marc* ;::>- pp D=6EE$
4le0ander- 9oger T$- James M$ %ieman and Jo*n 8iega- &'''# K$oping with -ava
programming stressL$ Computer <<#B- april &'''- pp <'6<=$
4llen- 9$ , D$ Garlan- ;::=# K' formal basis for architectural connectionL$ 8ersin
re+isada de 4CM Tran Soft (ng and Met*$- 1ul, ;::E$
4@S5V5((( ;::'# a/tandard 345.46748859 :lossary of /ofware Engineering
#echnologya- 5(((- @ew \or7$ ;::'$
+
%arbe,- St2p*ane and 4$ Stro*meier ;::B# K#he problematics of testing
objectoriented
softwareL$ 5n M 9oss- C$4$ %re+is- G$ Staples and J$ Stapleton .(ds$/ S`M
N:B Second conference on Software ùalit, Management- +ol$ &- pp B;;6B&D-
(dinburg*- Scotland- 3U- 1ul, &D6&= ;::B$
%arbe,- S$ ;::E# K;e test de logiciels < objetsL- Fn6line paper-
sawww$epfl$c*VS5CVS4VpublicationsVF5:EVfi6B6:EVB6:E6page<$*tml- 4bril- ;::E$
%ass- J$L$- !$ Clements- and 9$ Uaman- ;::E# K/oftware 'rchitecture in &racticeL-
4ddison6Cesle,- ;::E$
%as*ir 5$ and 4$L$ Goel &'''# K#esting object*oriented softwareL$ Springer- @ew
\or7
&'''
%(4- 5CL- 5%M- 5F@4- @etscape- Fracle- Sun- 3nis,s- 8isigenic ;::E# K$=>.'
components. -oint inicial /ubmission. DraftL$ FMG document orbosV:E6;;6&B-
no+ember ;::E$
%eier- %oris ;::'# K/oftware testing techniues2, &nd edition. 5nternational
T*omson
Computer !ress$
%eier- %oris ;::># K.lac? box testing2$ Jo*n Cile, and Sons- @ew \or7- ;::>$
%erard- ($8$ ;::<# KEssays on object*oriented software engineeringL- +ol 5- cap ;>-
!rentice6Jall- (nglewood Cliffs- ;::<$
%erg- U$ ;::E# a$omponent*based development9 no silver bullet$a$ Fb1ect
Magaine-
marc* ;::E
&;=
%inder- 9obert ;::Ba# K=bject*oriented software testingL$ Guest editor- C4CM + <E-
n :- sept ;::B- p &:$
%inder- 9$ 8$ ;::Bb KDesign for testability in object*oriented systemsL$ C4CM + <E-
n
:- sept$ :B- pp =E6;';
%inder- 9$ 8$ ;::># K#rends in testing object*oriented softwareL- in# Fb1ect oriented
tec*nolog,- a +irtual roundtable- Computer- october ;::>- pp D=6D:$
%inder- 9$8$ ;::D# K#esting object*oriented software9 a survey$L Software Testing-
8erification and 9eliabilit,- +$ D- pp ;&>6&>&- ;::D$
%inder- 9$ 8$ ;::E# K%ntroducing object*oriented testing9 what@s newA L- Fb1ect
magaine- 1ul,- ;::E$
%inder- 9$ 8$ ;::=# KHow to test !"; seuence diagram scenariosL Fb1ect
Magaine- =#; pp ;D6;:- ;::=$
%inder- 9$ 8$ ;:::# K#esting object*oriented systems. "odels, patterns, and toolsL$
4ddison Cesle, Longman- Fb1ect Friented Series- 9eading Mass$ ;:::$
%ooc*- G$ ;:=E# K/oftware components with 'da9 structures, tools, and
subsystemsL
%en1amin Cumins- 9edwood Cit,- C4- ;:=E
%ooc*- G$ ;::;# a=bject oriented design with applicationsa$ %en1amin Cummins
!ub$
Co$ 9edwood Cit,$
%o0- Don$ ;::=# KEssential $="2$ 4ddison Cesle, Longman- 9eading Mass$
;::=$
%ritis* Computer Societ,- Special 5nterest Group in Softwar Testing ;::E#$
a/tandard
for software component testinga$ +ersion <$<- april- ;::E$
%ronsard- F$- D$ %r,an- C$ Uoac,ns7i- ($ Liongosaru- J$ `$ @ing- 4$ Flafsson-
and
J$C$ Cetterstrand ;::E# a#oward software plug and playa$ !roc$ Ff t*e ;::E
s,mposium on software reusabilit, .SS9:E/- %oston- ;E6;: ma,o ;::E$
4parecidas
en Software (ngineering @otes- &&#<- ma, ;::E$
%rown- 4$C$ and U$C$ Callnau ;::=# K#he current state of $./E2$ 5((( Software-
septVoct ;::=- pp <E6BD$
%usc*mann- F$ 9$ Meunier- M$ 9o*nert- !$ Sommerlad- M$ Stal ;::D#
a&atternoriented
software architecture. ' system of patternsa$ Jo*n Cile, and Sons-
C*ic*ester- 3U$
C
Cant)- Marco ;::D# L"astering Delphi 6L$ S,be0- San Francisco- C4$- ;::D$
&;:
Councill- C$T$ ;:::# K#hird*party testing and the uality of the software
componentsL$ 5((( Software- ;D#B- pp >>6>E- 1ul,Vaugust ;:::$
C*appell- Da+id ;::E# K#he next wave. $omponent software enters the
mainstreamL$
C*ite papers- C*appell j 4ssociates- april ;::E$ www$c*appellassoc$com
C*en- M$J$- and J$M$ Uao ;::E# aEffect of class testing on the reliability of
objectoriented
programsa$ Tec*$ 9epo T9 :E6;- S3@\ at 4lban,- ;::E$
D
DNSoua- D$F$ and 4$C$ Cills ;::=# K=bjects, $omponents, and Bramewor?s with
!";9 the $atalysis approach2$ 4ddison Cesle, Longman- 9eading- Mass$ 3S4$
De+anbu- !$T$ and S$G$ Stubblebine &'''# L$ryptographic verification of test
coverage claims2$ 5((( transactions on Software (ngineering- &D#&- &'''- pp ;E=6
;:&$
-
Fernnde- J$M$ ;:::a# K&rueba de software basado en componentes CEstado
actual@ K 5nforme T2cnico- C5C- 5!@- serie +erde- n)mero &=- septiembre de ;:::$
Fernnde- J$M$ ;:::b# K'porte para una taxonom,a de defectos de software
basado en componentesL- Congreso 5nternacional de Computacin C5C::-
M20ico-
D$F$- no+iembre de ;:::
Fernnde- J$M$ &'''a K!n lenguaje descriptivo de aruitectura como facilitador
de
la prueba de software basado en componentesL- !rimer Taller 5nternacional de
Sistemas de 5nformacin- M20ico- septiembre de &''' a
Fernnde- J$M$ &'''b# K$asos de prueba para software basado en componentes
de la plataforma -ava 6L$ Congreso 5nternacional de Computacin C5C&'''-
M20ico-
DF- @o+$ &'''
Fernnde- J$M$ &'''c# K/ome conditions for $omponent*.ased /oftware
%ntegration #estingL$ =t* (uropean 5nternational Conference on Testing and
9e+iewing- (39FST49&'''- Copen*age- Dinamarca- Dec$ &'''$
Fernnde- JM$ &'';# K'>D!%&&9 modelando componentes de software2
Congreso
5nternacional de Computacin C5C'&- M20ico- DF- no+iembre de &''&$
Firesmit*- D$J$ ;::&# K#esting object*oriented software2- Tec*nical report- Fssian-
5nd$ 3S4$ ;::&
Firesmit*- Donald G$ ;::D# K&attern language for testing object*oriented softwareL$
&&'
Fb1ect magaine- feb$ ;::D- pp <&6<=
Fowler- M$ ;::E# K'nalysis &atterns9 >eusable =bject "odels2- 4ddison Cesle,
.;::E/
Fran7l- !*,llis- 9ic*ard Jamlet %e+ Littlewood and Loreno Strigini ;::E#
K$hoosing a testing method to deliver reliabilityL- 5CS( ;::E- pp D=6E=
G
Garlan- D and M$S*aw ;::B# K'n introduction to software architectureL$ Tec*$
report
CM3 CS6:B6;DD- Computer Science Dept$ Carnegie6Mellon 3ni+$- ;::B$
Garlan- D$- 9$ 4llen , J$ Fc7erbloom ;::># K'rchitectural mismatch9 why reuse is
so
hardL$ 5((( Software- ;&#D- pp ;E6&D- no+$ ;::>
Garlan- D$- 4J Uompane7 and !$ !into ;:::# K>econciling the needs of
architectural
description with object*modeling notationsL$ Draft submitted for publication- no+$
;::: .umloo$ps/$
Gra,- D$@$- J$ Jotc*7iss- S$ LaForge- 4$ S*alit and T$ Ceinberg ;::=# a"odern
;anguages and "icrosoft7s $omponent =bject "odela$ C4CM B;#>- pp >>6D>$
.
Jerum- !eter and Fli+er Sims &'''# K.usiness $omponent factoryL$ Jo*n Cile, j
Sons- @ew \or7- &'''
Joare- C49 ;:=># K$ommunicating seuential processesL- !rentice Jall- ;:=>
Jump*re,- Catts ;::E# K%ntroduction to the &ersonal /oftware &rocessL$ 4ddison
Cesle,- ;::E$
Junt- @eil$ ;::># a#esting object*oriented codea$ 9ational Software Tec*$ !apers$
*ttp#VVKKK.=58-9.5C./9:L1@;;9=8L86/M;5;6=1LF9@.75=H.M8:C
I
5%M ;::E# K/an Brancisco &roject #echnical /ummaryL$ 5%M ;::E$
www$ibm$comVJa+aVSanFranciscoVprdHSummar,$*tml
5((( ;::'# 5((( K/tandard glossary of /oftware Engineering technology2$ Std$
D;'$;&$ @ew \or7 ;::'
>
Jacobson- 5$- M$ C*risterson- !$ Jonsson , G$ k+ergaard ;::&# K=bject*oriented
&&;
software engineering. ' use case driven approachL$- 4ddison6Cesle, ;::&$
Jin- d$ and 4$J$ Fffutt ;::D# K$oupling based integration testingL$ &nd 5((( 5nt$
Conference on (ngineering of comple0 computer s,stems$ Montreal- Canada- pp
;'6;E- october :D$
Jorgensen- !$ C$ , C$ (ric7son ;::B# K=bject oriented integration testingL$ C4CM +
<E n :- sept$ ;::B- p <'6<=$
Jorgensen- !$C$ ;::># a/oftware testing. ' craftsman7s approacha- C9C !ress-
%oca
9atn- Florida- ;::>$
C
Uan- S$J$ ;::># a"etrics and models in software uality engineeringa- 4ddison6
Cesle,- 9eading- Ma$- 3S4- ;::>
Uicales- G$- J$ Lamping- 4$ Mend*e7ar- C$ Maeda- C$8$ Lopes- J$M$ Loingtier- J$
5rwin ;::E# a'spect*oriented programminga$ !roc$ of t*e (uropean Conf$ on
Fb1ectoriented
programming .(CFF!/$ Finland$ Springer 8erlag L@CS ;&B;- 1une ;::E$
Uit- ($ ;::># K/oftware #esting in the real 0orld2$ 4CM !ress64ddison Cesle,-
9eading Mass$ 3S4$- ;::>$
Uobr,n- C$ &'''# K"odeling components and framewor?s with !";L$ C4CM B<#;'-
october &'''- pp <;6<=$
Uoomen- T$ 4nd M$ !ol ;:::# K#est process improvementL 4ddison6Cesle, and
4CM- Jalow- (sse0- (ngland- ;:::
Urieguer- Da+id , 9ic*ard M$ 4dler$ ;::=# K#he emergence of distributed
component
platformsL$ 5((( Computer- + <;- n <- pp B<6><- marc* ;::=$
Uung- D$- J$ Gao- !$ Jsia- \$ To,os*ima and C$ C*en ;::># a' test strategy for
object*oriented programsa$ !roc$ Ff Computer Software and 4pplications
Conference- Te0as- 5(((6CS ;::>- pp &<:6&BB$
L
Landwe*r- C$($- 4$9$ %ull- J$!$ McDermott- C$S$ C*oi$ ;::B# K' taxonomy of
computer program security flaws2- Computing Sur+e,s- &D#<- pp &;;6&>B$
Lewandows7i- S$M$ ;::=# EBramewor?s for component*based clientFserver
computingE$ 4CM Computing Sur+e,s- <'#;- marc* ;::=- pp <6&E$
Lis7o+- %$ ;:==# aData abstraction and hierarchya$ S5G!L4@ @otices &<#>- ma,
;:==$
&&&
Luc7*am- D$ ;::D# K>apide9 a language and toolset for simulation of distributed
systems by partial ordering of eventsL- D5M4CS !artial Frder Met*ods Cor7s*op
58-
!rinceton 3ni+$- Jul, ;::D$ !uede *allarse en
*ttp#VVpa+g$stanford$eduVrapideVrapidepubs$
*tml$
M
Manns- T$S$ , Coleman- M$J$ ;::D# K/oftware Duality 'ssuranceL- Second edit$-
Macmillan- ;::D$
Martin- 9$ J$ , Fdell ;::D# K=bject oriented methodology9 pragmatic
considerationsL$
!rentice Jall- 3pper Saddle 9i+er- ;::D$
Ma,r*auser 4$ +on ;::'# a/oftware Engineering methods and managementa$
4cademic !ress- San Diego- 3S4$ ;::'
McGraw- Gar, and (dward Felten ;::E# K-ava securityL- Jo*n Cile,- @$\$- ;::E
Med+ido+ic- @$- D$S$ 9osenblum and 9$@$ Ta,lor ;:::# K' language and
environment for architecture*based software development and evolutionL- !roc$
&;st
5nternational Conference on software engineering .5CS(::/- Los lngeles- C4$ Ma,
;:::
Med+ido+ic- @enad- 9ic*ard @$ Ta,lor &'''# K' classification and comparison
framewor? software architecture description languageL$ 5((( Transactions on
Software (ngineering- &D#;- pp E'6:<- 1anuar, &'''
Me*ta- @$9$- @$ Med+ido+ic- S$ !*ad7e ;:::# K#owards a taxonomy of software
connectorsL$ Tec*$ 9epo$ 3ni+$ of Sout*ern California- ::6>&:
Me,er- %$ ;::E# a=bject oriented software constructiona- &nd$ De$- 3pper Saddle
9i+er- !rentice Jall- ;::E$
Me,er- %$ ;:::# K=n to componentsL$ 5((( Computer <&#;- 1anuar, ;:::- pp ;<:6
;B'$
Me,er- %$- C$ Mingins- J$ Sc*midt ;::=# G&roviding trusted components to the
industry2$ 5((( Computer- <;#>- pp ;'B6;'>- ma, :=$
Mic*ael- C$C$ and 9$C$ Jones ;::D# K=n the uniformity of error propagation in
software2$ Tec*$ 9eport 9ST96:D6''<6B- 9eliable Software Tec*nologies Corp$
Sterling- 84$ ;::D$
Moriconi- Mar7 and 9$4$ 9iemensc*neider ;::E# K%ntroduction to /'D; 4.5L S95
S,stem Design Laborator,- Terc*$ 9eport S956CSL6:E6';- ;::E$
Mosle,- Daniel J$ &'''# K$lient*/erver software testing on the des?top and the
webL$
&&<
!rentice Jall !T9- @ew Jerse,- &'''$
Musa- J$D$ ;::<# a=perational profiles in software reliability engineeringa$ 5(((
Software- marc* ;::<- pp ;B6<&$
M,ers- G$ ;:E:# K#he art of software testingL- Jo*n Cile, and Sons- @$\$- ;:E:$
N
@ierstras- F$ and L$ Dami ;::># K$omponent*oriented software technologyL in
@ierstras- F$ and D$ Tsic*ritis .(ds$/ KFb1ect6oriented software compositionL
!rentice Jall- (nglewood Cliff- @J- ;::E
@orris- Mar7- 9ob Da+is and 4lan !engell, &'''# K$omponent*based netwaor?
systems engineeringL- %oston- 4rtec* Jouse- &'''
O
Fb1ect Management Group ;::E# a$=>.' $omponent model reuest for
proposala$
Documento orbosV:D6'D6;&- 1une &- ;::E$
Fb1ect Management Group ;::=# Test Special 5nterest Group$ K#estingL w*ite
paper$
Fctober$ ;::=
Fffutt- 4$ Jefferson and Jane J Ja,es ;::D# K' semantic model of program faultsL$
!roc$ 5nternational S,mposium on Software Testing and 4nal,sis .5SST4:D/- San
Diego- 1anuar, ;::D
Frfali- 9$ and D$ Jar7e, ;::E# a$lient server programming with -ava and $=>.'a$
Jo*n Cile,$ ;::E
Frso- 4$ and S$ Sil+a ;::=# K=pen issues and research directions in object*
oriented
testingL$ !roc$ Bt*$ 5ntnml$ Conf$ Fn 4c*ie+ing ùalit, in Sofware- 5tal,- ;::=$
F+erbec7- J$ ;::B# K%ntegration testing for object*oriented software2, !*$D$
Dissertation- 8ienna 3ni+ersit, of tec*nolog,- 8iena- 4ustria$ ;::B
P
!errone- and C*aganti &'''# K.uilding -ava Enterprise /ystems with -6EEL S4MS$
!err,- D$($ and G$($ Uaiser ;::'# a'deuate testing and object*oriented
programminga- J$ Fb1ect6oriented programming- 8ol$ &- JanVFeb ;::'- pp ;<6;:$
!oore- J$J$- J$D$ Mills and D$ Mutc*ler ;::<# a&lanning and certifying software
system reliabilitya$ 5((( Software- 1anuar, ;::<- pp ==6::
&&B
!ope- 4lan ;::=# K#he $=>.' reference guide2$ 4ddison Cesle, Longman-
9eading Mass$ ;::=$
!urc*ase- J$4$ !urc*ase and 9$L$ Cinder ;::;# KDebugging tools for object*
oriented
programming2- JFF! B#<- ;::;- pp ;'6&E$
R
9edmond 555- F$($ ;:::# K%ntroduction to design and building 0indows DH'
applicationsL$ msdn$microsoft$comVlibrar,Vtec*artVwindnadesign6intro$*tm- 1une
;:::
9egnell %1nrn- !$ 9ueson and C$ Co*lin &'''# K#owards integration of use case
modelling and usage*based testingL$ Journal of s,stems and software- + >'- pp
;;E6
;<'- februar, &'''
9obbins- Jason- ($- @enad Med+ido+ic- Da+id F$ 9edmiles- Da+id S$ 9osenblum
;::=# K%ntegrating architecture description languages with a standard design
methodL$ !roc$ 5ntnNl Conf$ Fn Software (ngineering .5CS( ;::=/- U,oto- Japan-
april ;::=- pp &':6&;=$
9ogerson- Dale ;::E# K%nside $="L$ Microsoft !ress- 9edmond- Ca$- ;::E
9oman- ($ ;:::# K"astering Enterprise -ava.eans and the -ava 6 platform,
enterprise edition2$ Jo*n Cile, and Sons- @ew \or7- ;:::$
9osenblum- Da+id S$ ;::E# K'deuate testing of component*based softwareL$
Tec*nical report :E6<B- Dept$ Ff 5nformation and Computer Science- 3$ Ff
California65r+ine- ;; august ;::E
9osenblum- Da+id S$ ;::=# K$hallenges in exploiting architectural models for
software testingL$ 5nt$ Cor7s*op on t*e role of software arc*itectures in testing and
anal,sis- Sicilia- 5t$- ;::=$ pp B:6><
9umbaug*- J ;::;#a=bject oriented modeling and designa$ !rentice Jall-
(nglewood
Cliffs$ $ ;::;
S
Sametinger- J$ ;::E# K/oftware engineering with reusable componentsL- Springer
8erlag- Town- ;::E$
Selic- %ran and Jim 9umbaug* ;::=# K!sing !"; for modeling complex real*time
systemsL$ !rofile proposal en 9ational Software Corp$ ;::=
S*aw- Mar, and !$ Clements ;::D# K' field guide to .oxology9 preliminary
classification of architectural styles for software systemsL$ CM3 april ;::D$
&&>
S*aw- Mar, and D$ Garlan ;::D# K/oftware architecture. &erspectives on an
emerging disciplineL$ !rentice6Jall- 3pper Saddle 9i+er- @$J$- ;::D$
Siegel- Jon ;::D# K$=>.' Bundamentals I &rogrammingL$ Jo*n Cile, j Sons$-
;::D$
Siegel- S*el ;::D# K=bject =riented software testing9 a hierarchical approachL$
Jo*n
Cile, and Sons- @ew \or7- ;::D$
Sirer- ($G$ ;::=# aJimera 'rchitecturea$ Documento en lnea-
M88;2LLN-:6=5./1.K51M-.<89..67@L9G6=G-6K.M8:C
Smit*- M$D$ and D$J$ 9obson ;::'# K=bject*oriented programming. #he problems
of
validationL$ !roc$ 5((( Conf$ Software Maintenance- ;::'- pp &E&6&=;
Sousa Jooo !$ and Da+id Garlan ;:::# KBormal modeling of the Enterprise
-ava.eans $omponent %ntegration Bramewor?L- submitted for publication- ;:::$
S3@ ;::=#$ a'ssurance processa$ Documento en lnea-
M88;2LLO5G5.1@../9:L1((;6=/6.8L/;7L79/L;O/<L511@=5./6.79/1.M8:C
S3@ ;::E# K-ava .eans v. 4.542. S3@ Micros,stems 5nc$- ;::E
S3@ ;:::# KEnterprise -ava.eans /pecification, v4.4L !alo 4lto- C4- December
;:::
S,pers7i- C$ ;::E# K$omponent software. .eyond object*oriented programming2$
4ddison6Cesle, , 4CM !ress- ;::E$
T
Trusted Components ;:::#
*ttp#VVwww$eiffel$comVdocVmanualsVtec*nolog,VbmarticlesVcomputerVtrustedVpage$*t
ml
V
8elasco- !erla &'';# K&rueba de componentes de software basadas en el modelo
de -ava.eansL Tesis de Maestra en Ciencias en 5ngeniera en Computacin-
3ni+ersidad 4utnoma de Tla0cala- 4piaco- Tla0$ 4bril &'';$
8oas- Jeffre, M$- G$McGraw- L$ Uassab- L$ 8oas$ ;::E# K' 7crystal ball7 for software
liabilityL$ 5((( Computer <'#D- 1une ;::E- pp&:6<D$
8oas- Jeffre, M$ F$ C*arron- G$ McGraw- U$ Miller- M$ Friedman ;::E# K&redicting
how badly Ggood2 software can behave2$ 5((( Software +$ ;B- n$ B- pp E<6=<-
1ul,Vaugust ;::E$
&&D
8oas- Jeffre, M$ ;::=a# K#he challenges of using $=#/ software in
componentbased
developmentL$ Guest editorms introduction$ 5((( Computer- 1une ;::=- pp BB6
B>$
8oas- Jeffre, M$ ;::=b# K$ertifying off*the*shelf software componentsL$ 5(((
Computer- 1une ;::=- pp ><6 >:
7
Catson- 4$J$ and T$ J$ McCabe# ;::D# K/tructured testing9 a testing methodology
using the cyclomatic complexity metric2 Tec*$ 9epo$ @5ST >''6&&>$
Ce,u7er- ($ ;:=D# K'xiomati1ing software test data adeuacyL 5((( Tran$ Soft$
(ng$
S(;&#;&- ;:=D- pp ;;&=6;;<=$
Ce,u7er- ($ ;:==# K#he evaluation of program based software test data adeuacy
criteria2. Comm$ 4CM- <;#D- pp DD=6DE>$ ;:==$
Ce,u7er- ($ ;::=# K#esting component*based software9 a cautionary tale2$ 5(((
Software- septVoct ;::=- pp >B6>:
Cindows- &'''# K0indows 6555 0eb and application services2$ Tec*nical
o+er+iew$
C*ite !aper$
Q
\amaura- Tsuneo ;::=# KHow to design practical test casesL- 5((( Software + ;>-
n
D- no+emberVdecember ;::=- pp <'6<D$
&&E
A!1ndice A
M"de)ad" de e)e#ent"s de )a
!)ata$"r#a >a&a 5 usand" Ar3ui!!
(n este ap2ndice se presentan modelos de di+ersos elementos de la plataforma
Ja+a & que se consideran como componentes , conectores dentro del alcance del
traba1o$ (l modelado se reali de acuerdo con los elementos presentados en el
Captulo <$
Como se realian los modelos con 4rquipp , con los supuestos acerca de
conectores , componentes discutidos en el captulo <- los modelos no resultan
iguales a los mostrados en la documentacin propia de tales elementos ni a los
modelos propuestos por otros autores- empleando otras notaciones , supuestos$
Los elementos se presentan separados en componentes , conectores$
&&=
A*4* C"#!"nentes
Jasta el momento se *an analiado los tipos de componente que se muestran en
la tabla ; , que se describen a continuacin$ !odr notarse que no todos tienen el
mismo ni+el de detalle- aspecto que se corregir conforme se a+ance en el traba1o$
Tabla 4$;$ Tipos de componente
!ropios de Ja+a
4pplet
Ja+a%ean
Fb1eto remoto
Ser+let
(nterprise Ja+a%ean
4dicionales
4rc*i+o simple
Ceb browser
%ase de datos
Ser+idor e0terno
4lgunas consideraciones generales son las siguientes#
a/ los puertos no coinciden necesariamente con el concepto de interfa de Ja+aI
en algunos casos- +arias interfaces forman el puerto- como en el caso de los
(J%$
b/ Todo componente tiene- al menos- un puerto ofrecido- correspondiente a su
funcionalidadI si es el )nico que tiene- es un componente de ser+icio$
c/ Muc*os componentes de Ja+a tienen alg)n puerto obligatorio- pero usualmente
se les agregan otros que representan el uso de di+ersas tecnologas- como
transacciones o acceso a arc*i+os$ Los puertos obligatorios son los que se
describen en las secciones siguientes$
A.1.1 Applets.
3n 4pplet es una peque"a aplicacin que se e1ecuta dentro de un browser- pero
que es un elemento escrito en Ja+a$ Muc*os 4pplets estn escritos como
Ja+a%eans o grupos de ellos$ Su comunicacin bsica es con un browser , por
ello su estructura necesaria es como se muestra en la figura 4$;$
&&:
eecomponenteff
4pplet
seleccinQesttica
adaptacinQninguna
arc*6adaptaQnul
eepuertoff
com)nH*tml
naturaleaQofrecido
eelneaff
Solicitud
papelQentrada
tipoQe0tendido
eelneaff
9espuesta
papelQsalida
tipoQe0tendido
Figura 4$;$ (structura de un 4pplet$
A.1.2 .avaBeans.
Los Ja+a%eans pueden incluir muc*os elementos de la plataforma Ja+a &- pero
*a, dos que son mu, importantes# la capacidad de introspeccin , la de
comunicacin empleando e+entos$ 4s pues- en el modelo de la figura 4$& se
ilustran los puertos correspondientes a tales aspectos$ Ftros %eans que resulten
ms comple1os pueden remodelarse o *eredar de este modelo sus caractersticas
, agregar otras$
eecomponenteff
Ja+a%ean
seleccinQdespliegue
adaptacinQdespliegue
arc*6adaptaQnul
eepuertoff
p(+ento
naturaleaQofrecido
eepuertoff
W p(+ento
naturaleaQrequerido
eepuertoff
p5ntrospeccin
naturaleaQofrecido
!uede incluir uno o
ambos puertos pe+ento
, Wpe+ento
Figura 4$&$ Modelado de aspectos bsicos de Ja+a%eans
(n forma mnima- un Ja+a%ean tiene su puerto propio , el de introspeccinI
adems tiene al menos uno relacionado con e+entos .fuente o destino/- aunque
puede tener ambos$ Los puertos se describen en las Figuras 4$< , 4$B$
&<'
eepuertoff
p5ntrospeccin
naturaleaQofrecido
eelneaff
!regunta
papelQentrada
tipoQe0tendido
eelneaff
9espuesta
papelQsalida
tipoQe0tendido
Figura 4$< !uerto para introspeccin en Ja+a%eans
eepuertoff
p(+ento
naturaleaQofrecido
eelneaff
Funcin
papelQentrada
tipoQe0tendido
eelneaff
9espfun
papelQsalida
tipoQe0tendido
eelneaff
9eg
papelQentrada
tipoQe0tendido
eelneaff
Ja,e+ento
papelQsalida
tipoQe+ento
Figura 4$B !uerto de e+entos en Ja+a%eans
A.1.( Objeto remoto.
3n ob1eto remoto puede desplegarse independientemente en el mismo o diferente
equipo de donde se le in+ocar$ 3n ob1eto remoto se debe registrar ante el
ser+icio de nombres r#iregistr(- el cual ser+ir para localiarlo$ 3na +e
localiado se puede *acer uso de sus ser+icios , tambi2n recibir solicitudes de su
parte- en forma de callbac?$ La comunicacin entre ob1etos remotos , sus clientes
se realia a tra+2s de un conector 9M5 .remote method invocation/ o un conector
55F!$ (n la Figura 4$> se muestra este componente$
&<;
eecomponenteff
Fb1etoHremoto
seleccinQdinmica
adaptacinQninguna
arc*6adaptaQnul
eepuertoff
cone0in6rmi
naturaleaQrequerido
eepuertoff
comunica
naturaleaQofrecido
Figura 4$>$ Fb1eto remoto
La descripcin de sus puertos se *ace en las Figuras 4$D , 4$E$
eepuertoff
cone0in6rmi
naturaleaQrequerido
eelneaff
registro
papelQsalida
tipoQob1eto
eelneaff
recibe
papelQentrada
tipoQob1eto
Figura 4$D !uerto de cone0in 9M5
&<&
eepuertoff
comunica
naturaleaQofrecido
eelneaff
solicita
papelQsalida
tipoQe0tendido
eelneaff
responde
papelQsalida
tipoQe0tendido
eelneaff
reciberesp
papelQentrada
tipoQe0tendido
eelneaff
atiende
papelQentrada
tipoQe0tendido
Figura 4$E !uerto de comunicacin para ob1eto remoto
A.1.) /ervlets
Los ser+lets son peque"os elementos que permiten la creacin de pginas web en
lnea- usndose bsicamente para interfaces$ 9eciben solicitudes en formato de
*tml , responden con un te0to en *tml$ Traba1an en un ciclo de una sola
in+ocacin- pero son reutiliables- lo que los *ace mu, rpidos , capaces de
guardar informacin entre llamadas sucesi+as$ (n la figura 4$= se muestra su
estructura$
eecomponenteff
Ser+let
seleccinQesttica
adaptacinQninguna
arc*6adaptaQnul
eepuertoff
pser+let
naturaleaQofrecido
eelneaff
ent
papelQentrada
tipoQser+let9equest
eelneaff
sal
papelQsalida
tipoQser+let9esponse
Figura 4$= (structura de ser+let
A.1.4 *nterprise .avaBean
Los Enterprise -ava.eans- (J% o beans- son componentes mane1ados a tra+2s de
un contenedor especial , que permiten construir aplicaciones de tipo
clienteser+idor
o de +arios ni+eles- posiblemente distribuidas- en forma transparente$ Los
&<<
(J% descansan en el mecanismo 9M5655F!- usando como au0iliares +arios ob1etos
remotos- llamados Jome ob1ect , 9emote ob1ect$ (l primero sir+e como factora
para construir el segundo- el cual delega las llamadas a una instancia del (J%
creada o reutiliada por el contenedor$ (n el caso de reutiliacin se utilia un pool
de instancias para atender di+ersas llamadas$ Los (J% se localian , luego se
pueden crear usando las lneas Home , luego se usa +a las lneas >emote , su
funcionalidad propia$ (n la Figura 4$: se muestra la estructura principal , en las
Figuras 4$;' , 4$;; se muestran sus puertos$
eecomponenteff
(J%
seleccinQdinmica
arc*6adaptaQnul
eepuertoff
cone0in6e1b
naturaleaQrequerido
eepuertoff
comunica(1b
naturaleaQofrecido
Figura 4$: (structura bsica de un (J%
Los (J% de sesin no se comparten durante su acti+idad- a)n cuando pueden ser
reutiliados- pero sin el estado que pudieran *aber tenido$ (n cambio- los (J% de
entidad- dedicados a almacenar datos- s son compartidos , por ello debe ponerse
cuidado especial en su mane1o$
&<B
eepuertoff
cone0in6e1b
naturaleaQrequerido
eelneaff
registro
papelQsalida
tipoQe0tendido
Figura 4$;' !uerto de cone0in (J%
eelneaff
*ome
papelQentrada
tipoQe0tendido
eelneaff
remote
papelQentrada
tipoQe0tendido
eelneaff
remoteresp
papelQsalida
tipoQe0tendido
eelneaff
responde
papelQsalida
tipoQe0tendido
eelneaff
propio
papelQentrada
tipoQe0tendido
eelneaff
*omeresp
papelQsalida
tipoQe0tendido
eepuertoff
comunica(1b
naturaleaQofrecido
Figura 4$;; !uerto de comunicacin con (J%
&<>
Los (J%- por su papel en sistemas de empresa- utilian ser+icios transaccionales$
(stos se especifican al tiempo de despliegue ,- preferentemente- se de1an en
manos del contenedor .forma declarati+a/ quien lo implementa a tra+2s del ob1eto
remoto que representa al bean$ Sin embargo el bean puede administrar las
transacciones$ !or a*ora no se muestra su modelo$
A.1.5 Arc0ivo simple.
3n arc*i+o simple representa un con1unto de datos que pueden ser la entrada o la
salida de un proceso$ 4)n cuando su estructura es mu, simple- siguen siendo
importantes en la programacin moderna$ (n cierto sentido pueden +erse como un
elemento que recibe un comando de lectura , regresa un dato o recibe un
comando de escritura , un dato que almacena$
(ste tipo de elementos .pasi+os/ se conectan a otros componentes .acti+os/ de
Ja+a a tra+2s de un conector de tipo strea#$
3sando el LD4 propuesto- su representacin queda como en la Figura 4$;&$
eecomponenteff
4rc*i+o
SeleccinQdinmica
4daptacinQninguna
4rc*HadaptaQnulo
eepuertoff
(ntraHsale
naturaleaQofrecido
eelneaff
Solicitud
papelQentrada
tipoQe0tendido
eelneaff
9espuesta
papelQsalida
tipoQe0tendido
Figura 4$;& Descripcin del tipo arc*i+o
A.1.: Ceb bro#ser.
Como web browser se entender todo tipo de cliente que in+oca alg)n ser+icio
web a tra+2s de conectores tipo Jttp- pudiendo ser un browser en sentido estricto
o alguna aplicacin que *aga esa funcin$
4)n cuando los browsers tienen una gran +ariedad de capacidades- la parte que
interesa para este traba1o es la que permite a este tipo de componente conectarse
con otros a tra+2s de una red$ (ste mecanismo emplea bsicamente una lnea de
9equest , una de 9ecei+e para en+iar solicitudes codificadas de acuerdo a Jttp ,
recibir respuesta en forma similar ?+er !erroneX- &'''A$
&<D
4s- la estructura de un componente de este tipo ser como la que se muestra en
la figura 4$;<$
eecomponenteff
Ceb browser
seleccinQesttica
arc*6adaptaQnul
eepuertoff
Wcom)nH*tml
naturaleaQrequerido
eelneaff
Solicitud
papelQsalida
tipoQe0tendido
eelneaff
9espuesta
papelQentrada
tipoQe0tendido
Figura 4$;<$ (structura de un web browser$
A.1.; Base e atos
3na base de datos- tal como las mane1a Ja+a- puede modelarse en forma mu,
seme1ante a un arc*i+o- como se muestra en la Figura 4$;B$ Sin embargo- en su
mane1o *abr diferencias atribuibles a su conector- que no es igual al de un
arc*i+o$ 3na diferencia consiste en el tipo de datos , de rdenes que recibe el
puerto# un arc*i+o recibe rdenes simples de leer , escribir elementos- mientras
que una base de datos recibe rdenes ms comple1as$ Los datos en+iados
tambi2n son diferentes- ,a que una base de datos usualmente responde con todo
un con1unto de datos$ Sin embargo- para fines de modelado el problema es mu,
similar$
eecomponenteff
%ase de datos
SeleccinQdinmica
4daptacinQninguna
4rc*HadaptaQnulo
eepuertoff
(ntraHsale
naturaleaQofrecido
Figura 4$;B %ase de datos
&<E
A.1.= /ervior e9terno
Ja, +arios ser+idores e0ternos que pueden emplearse desde otros componentes
de una aplicacin$ Tales ser+idores +ienen a ser aplicaciones- pero aceptan
conectarse dinmicamente$ (n este traba1o se considera )nicamente aquellas que
se enlaan +a el mecanismo de soc7et- para lo cual emplean dos puertos
seme1antes al de un arc*i+o$ La Figura 4$;> muestra la estructura , en la Figura
4$;< se muestra la *erencia de sus puertos$ (n forma seme1ante a la base de
datos- el contenido de los datos que mane1an sus puertos es ms comple1o que el
de un arc*i+o- pero conceptualmente es igual$
eecomponenteff
Ser+idor e0terno
SeleccinQdinmica
4daptacinQninguna
4rc*HadaptaQnulo
eepuertoff
(ntrada
naturaleaQofrecido
eepuertoff
Salida
naturaleaQofrecido
Figura 4$;> (structura de ser+idor e0terno
eepuertoff
(ntraHsale
naturaleaQofrecido
eepuertoff
(ntrada
naturaleaQofrecido
eepuertoff
Salida
naturaleaQofrecido
Figura 4$;D !uertos de ser+idor e0terno
&<=
A*5* C"nect"res
(n esta seccin se describen los conectores de tipo incluido en la Tabla 4$&- en la
cual se indican- adems- los tipos de componente o conector a los que conecta$
!ara cada tipo se presenta su descripcin , su modelado con el LD4 propuesto$
Tabla 4$&$ Tipos de conector
Ti!" de c"nect"r
Ti!" de c"#!"nente
base9 c"ntened"ra "
acti&a
Ti!" de c"nect"r9
c"#!"nente au8i)iar9
c"ntenida " !asi&a
(+entos Ja+a%ean Ja+a%ean
Jttp Ceb browser 4pplet- conHser+let
ConHser+let Jttp Ser+let
9mi 4plicacin- applet Fb1eto remoto
ConHe1b 4plicacin- applet- ser+let (1b
Stream 4plicacin- applet- 4rc*i+o simple
Jdbc 4plicacin %ase de datos
Soc7et 4plicacin Ser+idor e0terno
A.2.1 *ventos
3n elemento importante en la comunicacin entre componentes concurrentes del
tipo Ja+a%eans es el conector de e+entos- que en+a a+iso de la ocurrencia de un
e+ento en un componente fuente a uno o ms destinos$ (l e+ento contiene
informacin del emisor , puede lle+ar otros datos$ 4l recibir un e+ento- un
componente puede solicitar otros ser+icios del emisor a tra+2s de su identificacin
recibida$ !ara que funcione el conector- cada componente destino debe ligarse-
por s o a tra+2s de un tercero- con el emisorI tambi2n puede desligarse en forma
similar$ (n la figura 4$;E se muestran los principales elementos de 2ste tipo de
conector$
&<:
eeconectorff
(+ento
localidadQlocal
eepuertoff
p(+ento
naturaleaQofrecido
eepuertoff
Wp(+ento
naturaleaQrequerido
Figura 4$;E$ Modelado del conector (+ento
Debe notarse que la implementacin particular de e+entos en Ja+a & re)ne todas
las llamadas en una sola estructura de datos , los a+isos se en+an a todos los
elementos registrados- como un solo conector- pero su representacin de tal modo
resulta ms comple1a de lo necesario para los fines de este traba1o- por lo cual se
prefiri de1ar cada enlace grficamente separado$
La interaccin representada por el conector (+ento se puede representar como
en la figura 4$;=$
;#registra
;V&#a+isa
&V< g?'$$nA# a+isa
&VB g?'$$nA consulta
&-<-BV># desregistra
p(+ento
9eg Ja,(+ento Funcin 9espFun
Wp(+ento
9eg Ja,(+ento Funcin 9espFun
Figura 4$;=$ Diagrama de secuencia para conector de e+entos$
!ara entender el funcionamiento de este conector se puede emplear un diagrama
de estados- como se muestra en la Figura 4$;:$ (n este se indican los cambios de
&B'
estado por medio de una condicin sobre papeles- como Kconsulta$5nicioL que
puede estar acti+a- , una accin o postcondicin como Kacti+ar consulta$9ecibeL$
inacti+o
registro$!ide acti+a
V acti+ar registro$4cepta
desregistro $!ide acti+a
V acti+ar desregistro$4cepta
a+iso$5nicia acti+o
V acti+ar a+iso$9ecibe
consulta$5nicio acti+a
V acti+ar consulta$9ecibe
*a, enlaces
Figura 4$;:$ Diagrama de estados de la interaccin de (+ento
A.2.2 Http
(l conector *ttp se utilia para comunicar un web browser o aplicacin
equi+alente- con un componente o aplicacin remoto .applet- ser+let u otro/- +a
ser+idores de red$ (s un conector que combina funciones de comunicacin , de
control sobre un mismo par de puertos$ Sigue el formato del CG5;E que en+a un
comando 1unto con sus datos en una sola cadena de caracteres , regresa otra
cadena de caracteres que lle+a un encabeado a+isando el tipo de documento que
representa la cadena$ (l conector utilia el comando para localiar , acti+ar el
ser+idor destino , le pasa los datos adicionales$ 4l regreso transmite los datos
como se los en+an$
(n la Figura 4$&' se muestra la estructura del conector , se complementa con la
Figura 4$&; que muestra el puerto asociado$
;E Common Gatewa, 5nterface
&B;
eeconectorff
*ttp
LocalidadQred
eeenlaceff
e*ttp
control
eepuertoff
p*ttp
@aturaleaQofrecido
eepuertoff
Wp*ttp
@aturaleaQrequerido
Figura 4$&' (structura del conector *ttp
eepuertoff
!*ttp
@aturaleaQofrecido
eelneaff
sal
!apelQsalida
TipoQcadena de
caracteres
eelneaff
ent
!apelQentrada
TipoQcadena de
caracteres
Figura 4$&; !uerto p*ttp
(n la Figura 4$&& se muestra la interaccin- donde 1uega un papel importante el
propio conector$ !ara fines del usuario- se podra omitir- concatenando las flec*as
de iquierda a derec*a en una sola$
&B&
W!*ttp
(nt Sal
!*ttp
(nt Sal
*ttp
cliente ser+idor
ComandoXdatos ent
Datos ent
Datos sal
Figura 4$&& 5nteraccin del conector *ttp
A.2.( ConDservlet
(l conector conHser+let permite la comunicacin con un ser+let$ Muc*as +eces se
emplea concatenado con el conector *ttp- pero no es obligatorio$ (ste conector
recibe- por el lado del cliente- datos que acti+an un proceso , regresa resultados
para desacti+arse$ !or el lado del ser+let los datos aparecen como ob1etos de tipo
ser+let9equest , ser+let9esponse$ 4s pues- este conector 1uega un papel acti+o
transformando los datos$ (n la Figura 4$&< se muestra su estructura$ (n la Figura
4$&B se muestra el puerto pser+let- que complementa la estructura$
eeconectorff
ConHser+let
LocalidadQred
eeenlaceff
eser+let
eepuertoff
pser+let
@aturaleaQofrecido
eepuertoff
Wp*ttp
@aturaleaQrequerido
Figura 4$&< (structura del conector conHser+let
&B<
eepuertoff
!ser+let
@aturaleaQofrecido
eelneaff
sal
!apelQsalida
TipoQser+let9esponse
eelneaff
ent
!apelQentrada
TipoQser+let9equest
Figura 4$&B !uerto pser+let
La interaccin correspondiente al conector se muestra en la figura 4$&>$ 4l igual
que en el caso de *ttp- se puede omitir la presencia del propio conector
concatenando las flec*as que +an en la misma direccin$
W!*ttp
(nt Sal
!ser+let
(nt Sal
*ttp
cliente ser+idor
Datos ent
Datos ent
Datos sal
Datos sal
Figura 4$&> 5nteraccin del conector conHser+let
A.2.) 1mi
(ste conector comunica clientes con ob1etos remotosI tiene dos enlaces# uno con
ser+icios de comunicacin que permite interactuar al cliente con el ob1eto remoto
.en las dos direcciones/ , uno de control con dos copias# uno para el cliente , otro
para el ob1eto remoto- que permite registrar al ob1eto remoto ante el ser+icio de
nombres , localiar el ob1eto a pedido de un cliente$ Sus enlaces se muestran en
la Figura 4$&D , su estructura se muestra en la Figura 4$&E- omitiendo las
interacciones$
&BB
eeenlaceff
cone0in6rmi
categoraQcontrol
eelnealff
registro
papelQsalida
tipoQob1eto
eelneaff
9ecibe
papelQentrada
tipoQob1eto
eeenlaceff
comunica
eelneaff
Solicita
papelQsalida
tipoQe0tendido
eelneaff
4tiende
papelQentrada
tipoQe0tendido
eelneaff
9esponde
papelQsalida
tipoQe0tendido
eelneaff
9ecibe9esp
papelQentrada
tipoQe0tendido
Figura 4$&D (nlaces del conector 9M5
(ste conector tiene dos interacciones bsicas# la que se refiere al control , la de
comunicacin$ 3sualmente la primera se realia una sola +e , la segunda
muc*as +eces$ (n las Figuras 4$&= , 4$&: se presentan las interacciones$
&B>
eeconectorff
9M5
localidadQred
eeenlaceff
cone0in6rmi
categoraQcontrol
eeenlaceff
comunica
&
Figura 4$&E (structura del conector 9M5
Cliente
registro recibe
Ser+idor
registro recibe 9M5
Solicita.registro-
nombre/
Solicita.busca-
nombre/
Figura 4$&= 5nteraccin de control
&BD
Lado del
cliente
Lado del
ser+idor
g 5n+oca funcin del cliente
g 5n+oca funcin del ser+idor
4tiende responde solicita recibe9esp 4tiende responde solicita recibe9esp
Figura 4$&: 5nteraccin de comunicacin
A.2.4 Conector *.B
(l conector con(J% se puede describir en dos partes- correspondientes a los dos
puertos$ La primera corresponde a las funciones de ser+icio- donde el (J% es
registrado ante el contenedor , el cliente lo solicita$ (sta parte se muestra en la
figura 4$<' , es mu, similar a la del conector 9M5$
La interaccin entre el cliente , el (J% se realia una +e que el cliente *a
recuperado la referencia al ob1eto Jome$ (sta interaccin in+olucra seis lneas-
como se aprecia en la figura 4$<;$
cliente (J% con(J%
9egistro
.despliegue/
localia
referencia
Figura 4$<' 5nteraccin de ser+icio del conector Con(1b
&BE
(J%- puerto comunica(1b Cliente- puerto comuica(1b
a; a& *ome *omeresp
;# in+oca
remoteresp remote b; b&
&# in+oca
propio responde c; c&
< ?'$$nA#funcin
<VB# termina
Figura 4$<; 5nteraccin entre cliente , (J%
A.2.5 /tream
(l conector Stream no es tpico de componentes en sentido comercial- pero se le
utilia ampliamente- por lo cual se le inclu,e$ !ara fines de modelado es mu,
sencillo- ,a que transmite rdenes , datos por una lnea , regresa datos , a+isos
por otra$ (n la Figura 4$<& se muestra su estructura , en la figura 4$<< se muestra
sun interaccin tpica$
eeconectorff
Stream
LocalidadQlocal
eeenlaceff
(Hstream
eepuertoff
(ntraHsale
@aturaleaQofrecido
eepuertoff
W(ntraHsale
@aturaleaQrequerido
Figura 4$<& (structura del conector Stream
(l puerto (ntraHsale no se detalla pues se present al describir el componente
4rc*i+o .seccin 4$;$D/$
&B=
(ntraHsale
(ntrada 9espuesta
W(ntraHsale
(ntrada 9espuesta
4brir./
g leer./Vescribir.datos/
Cerrar./
Figura 4$<< 5nteraccin en conector Stream
A.2.: .bc8obc
(l conector 1dbc6odbc se emplea para acceder a bases de datos desde
componentes Ja+a$ (n realidad tiene al menos dos partes# el conector propio de la
plataforma Ja+a- llamado 6dbc- , el conector estndar de Microsoft "dbc$ (n
muc*os casos se les mane1a 1untos , por eso se les tratar como uno solo$
(ste conector permite que un componente localice , se conecte con una base de
datos que puede ser local o remota- +a red$ 3na +e conectado- puede realiar
todo tipo de operaciones permitidas por el estndar S`L , aceptadas por la base
de datos particular .algunas pueden ser de slo lectura/$
(n cierta forma- este conector es similar al de 9M5 en que necesita un paso de
localiacin +a el conector , luego otra de comunicacin$ Sin embargo- a
diferencia de 9M5 la base de datos no necesita registrarse , se emplea el sistema
de localiacin de 5nternet$
(n la figura 4$ se presenta un detalle
del puerto de control$ La interaccin de control- correspondiente a la localiacin ,
cone0in con la base de datos aparece en la figura 4$<D$
&B:
eepuertoff
JdbcHcontacto
naturaleaQrequerido
eeconectorff
Jdbc6odbc
LocalidadQlocal
eeenlaceff
JdbcHuso
eepuertoff
(ntraHsale
@aturaleaQofrecido
eepuertoff
W(ntraHsale
@aturaleaQrequerido
eeenlaceff
Contacta
CategoraQcontrol
Figura 4$ !uerto de control del conector 1dbc6odbc
JdbcHcontacto
%usca 9espuesta
Jdbc6odbc
%usca.identificacin/
Figura 4$<D 5nteraccin de cone0in en el conector 1dbc6odbc
La interaccin de uso de la base de datos es similar a la de Stream- pero tiene
algunas diferencias$ .+er Figura 4$<E/$ 4 pesar de las diferencias- el tipo de
puertos es el mismo- aunque en este caso se transmiten datos ms comple1os$
&>'
(ntraHsale
(ntrada 9espuesta
W(ntraHsale
(ntrada 9espuesta
g e1ecuta.datos sql/
Cerrar./
Figura 4$<E 5nteraccin de uso de base de datso en 1dbc6odbc
A.2.; /oc3et
(l conector Soc7et es mu, antiguo , no e0clusi+o de componentes- pero se usa
para acceder a algunos ser+idores e0ternos- como los tratados en la seccin
4$;$:$ Su operacin est mu, ligada a Stream , en la prctica funciona como dos
streams# uno de entrada , otro de salida$ 4dems de los streams- emplea un
mecanismo de localiacin seme1ante al de 1dbc6odbc- que permite localiar el
ser+idor fuera del proceso , a)n del equipo que lo in+oca$ (n la figura 4$<= se
presenta su estructura$
Los puertos (ntrada- Salida , sus con1ugados son id2nticos a (ntraHsale que se
describi en la seccin 4$;$D
La interaccin correspondiente al control de este conector es- para fines de
modelado- igual a la del conector 1dbc6odbc- por lo cual no se detalla$ La
interaccin de comunicacin se muestra en la figura 4$<:$
@tense las cone0iones cruadas de los puertos que 1uegan papel de entrada ,
salida$
Los datos que intercambia un componente cliente con un ser+idor de esta
naturalea dependen del ser+icio deseado$ !or e1emplo puede tratarse de un
ser+idor de correo- para el cual se usa el protocolo SMT!$
&>;
eepuertoff
soc7etHcontacto
naturaleaQrequerido
eeconectorff
soc7et
LocalidadQlocal
eeenlaceff
soc7etHuso
eepuertoff
(ntrada
@aturaleaQofrecido
eepuertoff
W(ntrada
@aturaleaQrequerido
eeenlaceff
Contacta
CategoraQcontrol
eepuertoff
Salida
@aturaleaQofrecido
eepuertoff
WSalida
@aturaleaQrequerido
Figura 4$<= (structura del conector Soc7et
W(ntrada
(ntrada 9espuesta
Salida
(ntrada 9espuesta
g lee.datos/
(ntrada
(ntrada 9espuesta
WSalida
(ntrada 9espuesta
g escribe.datos/
Cliente Ser+idor
Figura 4$<: 5nteraccin de comunicacin en Soc7et

Pruebas de Integración para Componentes de Software

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Pruebas de Integración para Componentes de Software

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUTO POLITCNICO NACIONAL

Anda mungkin juga menyukai