Diseodeinterfacesentrecomponentes

Diseo de interfaces entre componentes

Estudio del grado y forma de acoplamiento entre partes de un sistema
FernandoDodino,NicolsPasserini,FrancoBulgarelli

Versin2.4
Abril2015

1Interaccinentredoscomponentes
1.1Digresin:porqucomponente?
2Interfacesentrantesysalientes
2.1Interfazentrante
2.2Interfazsaliente
3Ambientes
3.1Todoenunsololugar
3.2Distintosambientes
4Interfacessincrnicasyasincrnicas
4.1Interfacessincrnicas
4.2Interfacessincrnicas
4.2.1Buffers
5AlgunaspalabrassobrelasFachadas(Faades)
5.1AdvertenciassobreelFaade
5.2MalosusosdelFaade
6Ejercicioprctico:compracontarjetadecrdito
6.1Interfazsaliente
6.1.1Cmoquedalacompraenelcdigo
6.1.2ManejodeErroresenlainterfaz
6.2Interfazentrante
6.2.1Cmodefinirlainterfazentrante

1de18

Diseodeinterfacesentrecomponentes

1 Interaccin entre dos componentes

Volvemosunavezmsadecirqueunsistemaesunconjuntodecomponentesquese
relacionanparalograrunobjetivocomn.Ahorabien,cmoserelacionanesos
componentes?

SupongamosqueA"necesitaalgo"deB.Loquenosvaainteresaresverqualternativas
tengoparamodelaresalneapunteada.

Algunascosasatenerencuenta:
Direccinysentidodelacomunicacin:
silacomunicacinvadeAhaciaB(controldirecto)oalrevs(inversinde
control)
silacomunicacinentreAyBesbidireccionalounidireccional
SiAyBestnambosenelmismoambiente
Manejodeerrores
qupasasihayunerrordeconexinconB1
qupasasihayerrorcuandoBprocesaelpedidodeA
Gradodedependencia:
siAesperaractivamenteaqueBterminedeprocesar(esdecir,sila
comunicacinessincrnica)2opuedecontinuartrabajandosinbloquearse
(comunicacinasincrnica)
siAnecesitaalgnresultadodeBosisimplementedebenotificarloy
olvidarse(fireandforget)
determinarsiinteresaqueBproceseelpedidodeAenformaexitosaparaqueA
hagaotrascosasenlamismatransaccin
determinarsisenecesitareprocesar(enformamanualoautomtica)determinados
mensajesdeAaB
determinarsisenecesitaobtenerunlog(llevarunregistro)delospedidosenviadosa
B
etc

Lasdecisionesquetomemosimpactarnen
elgradoyformadeacoplamientoentrelos
componentesdenuestrosistem
a.Poreso,acontinuacintrataremosvariasdeestas
cuestiones.

1
2

Leertambinapuntedemanejodeerrores
Leertambin
apuntedecomunicacinentrecomponentes

2de18

Diseodeinterfacesentrecomponentes

1.1 Digresin: por qu componente?

Lasideasqueestamosmencionandoaplicannoslocuandocomponente=objeto.
Podemosmencionardiferentesnivelesparadisearcomponentes,enunaclasificacinque
noestaxativa,sinoqueintentaordenarunpoconuestrospensamientos:
Microdiseo,niveldeprograma,piensoenobjetos,clases,procedimientos,
funciones
Nivelmedio,muchosobjetosformanuncomponente/mdulo/packageypiensola
integracindeesascosas
Nivelarquitecturadesoftware,elnivelmsaltodentrodemiaplicacin,veolos
elementosprincipalesdemiaplicacinycmoseintegranentres.
Nivel"arquitecturadesistema",pensandoelsistemacomounconjuntodepiezasde
softwareointegracinentresistemas.Piensocmoseintegranlossistemas/
aplicacionesentres.

Lospatronesqueveremosacontinuacinsonaplicablesacualquieradeestosniveles,ms
alldequeloscomponentesqueelijamosennuestrosejemplosseanpequeospor
cuestionesdidcticas.

2 Interfaces entrantes y salientes

Nosencontramosdiseandouncomponente.Primero,respondamosunapreguntafcil
respectoalproblemadelacomuncacin:estamosdiseandolaformadequeotros
componentes"hablen"conelnuestro,olaformadeconectarnosaotrocomponente?Es
decir,estamosdiseandounainterfazentranteosaliente?

Analicemosamboscasos.

Cuidado:esimportantenotarquelatecnologaenlaqueestnimplementadoslos
componentesquesecomunicarnconelnuestropodrasermuydiferenteaaquellacon
laquetrabajamos.

2.1 Interfaz entrante

Cuandoestamosenestasituacin,tenemosquepensarcualeslainformacinquenuestro
componente(B,enelejemplo)necesitapararesolversutarea,ycmonosconviene

3de18

Diseodeinterfacesentrecomponentes

recibirla.Tendremosqueconsiderarquelasdecisionesquetomemosimpactarnencuan
fcilesparaotrosmiembrosdeunequipodedesarrollousarestecomponente.

2.2 Interfaz saliente

Ahoranosencontramosenlasituacincontraria:estamosdesarrollandouncomponenteque
necesitadelegarenotrociertastareas.Ahoratenemosquepreocuparnosporproveerla
informacinqueste(enelejemplo,B)necesita,adaptndonosalaformaquenospropone
decomunicacin.

3 Ambientes

Debemosentenderqueeldiseodelacomunicacinentrecomponentesesbastante
diferentecuandoloscomponentesestnenelmismoodiferenteambiente.

3.1 Todo en un solo lugar

AyBpuedensermdulosqueconvivenenelmismoambiente.

Aqunotenemosmayoresrestriccionesencuantoalacomunicacin.Siestamostrabajando
conobjetosestoestansencillocomoenviarunmensajeaunobjetoyya.

AyBsepiensancomocomponentesquetienenunaseparacinlgicaentres:

PorqueAoBpuedenestardesarrolladosporotros(objetosdelaJDK,de
frameworksdeterceraspartes,degruposdetrabajoquenoformanpartedela
mismagerenciaalaquepertenecemos,etc.)
AuncuandoAyBsoncomponentesquenosotrosmismosdesarrollamos,tratamos
dereducirsuacoplamiento.Ojo,loscomponentestienenrelacinentresyestmuy
bienquelatengannoquieroeliminarlainteraccin,sevitarqueAconozca

4de18

Diseodeinterfacesentrecomponentes

demasiadodeBoviceversa.Entoncespuedopensarunainterfazquemepermita
cambiarimplementacionesposiblesparaB:
porquenotengoimplementadoBperonecesitoirtesteandoA,entoncesarmo
unaimplementacinmnimadeBquerespondaalmensajedeAparaluego
reemplazarlaporlaimplementacinrealdeB
porqueBnotieneelalcancecerradoyquierodejarlapuertaabiertaparalos
cambiosquesequevanavenir
oporcualquierotraraznquelojustifique

3.2 Distintos ambientes

Enelsegundocaso,AyBestnimplementadosendistintoslugares(componenteremoto),
distintastecnologasoinclusodesarrolladosbajodiferentesparadigmas.

Sibienesimposibleindependizarsecompletamentedecuestionescomolatecnologaola
ubicacindeestoscomponentes3 (estnlamismacomputadora?Odebemosaccederlos
atravsdelareddeInternet?),intentaremosqueestonosafectelomenosposible.

Porqu?Porquenosinteresaminimizarelacoplamientoentreloscomponentes.As,sipor
ejemploestamosdesarrollandocomponentesbajoelparadigmadeobjetos,nosinteresar
disearlasinterfacesbajoesteparadigma.

Siparapoderhacerqueloscomponentessecomuniquenconalgomuydiferente,ser
necesariaunatransformacin,peronoserpartedemicomponente,sinoqueserun
elementoindependientequesdependerdelatecnologa,peroquedeberaestar
desacopladodelainterfaz.

Entonceselobjetivoesseparar
lalgicadecomunicacinanivelnegocio:ququierodecir,quinformacindebo
pasar,quesperorecibir,querroresdenegociopodranocurrir
delalgicadetransformacinquefueranecesaria.

T es el componente que hace algn tipo de transformacin. Puede estar en alguno de los
dos ambientes, o en otro ambiente aparte. No es objetivo de la materia desarrollar el
componenteT.

Losrequerimientosnofuncionales,aligualqueeldiablo,estnenlosdetalles

5de18

Diseodeinterfacesentrecomponentes

4 Interfaces sincrnicas y asincrnicas

Otrapreguntaaresponderes:cuandoelcomponenteAsecomunicaconB,enqugrado
necesitaAlosresultadosdeB?Tenemosdosopciones:comunicacionessincrnicasy
asincrnicas.

4.1 Interfaces sincrnicas

Sedacuandouncomponenteleenvaunmensajeaotro,stesequedaesperandoaqueel
otrotermine.Estaeslaformaenquetrabajaelenvodemensajesenobjetos,laejecucin
deprocedimientosenimperativo,olaaplicacindefuncionesenfuncional.

Estambinlaformamssimpledetrabajar,porqueesfcilrazonarsobreella:siun
componenteAleenvaunmensajeaotroB,yluegoAleenvootromensajeaC,sabemos
conseguridadquelarespuestadeCllegardespusdelarespuestadeB.

Unejemplo:nosinteresaconocerlacotizacindeldlardelafechadehoy.Sinos
paramosdesdeelcomponenteAypensamosenhablarconuncomponenteBque
obtienelacotizacin,unaopcinsincrnicaeslasiguiente:

BigDecimal dolarHoy = cotizador.obtenerCotizacion()

Lointeresantedelsincronismoesquesabemosquesilalineaterminadeejecutarsesin
errores,tendremoscontotalseguridadunresultado,queusarloenelsiguienteenvode
mensajes:

BigDecimal precioFinal =
calculadoraPrecios.obtenerPrecioFinal(dolarHoy)

LacontradeestaformadecomunicarnosesquesilacomunicacinentreAyBeslentao
pococonfiable 4,detendrlaejecucindelcomponenteAporquizsdemasiadotiempo.

4.2 Interfaces asincrnicas

CuandoAestencondicionesdecontinuarsutrabajomientrasBcalculaelresultado,o
incluso,cuandoaAnoleimportaelresultadodeB,podemosimplementarinterfaces
asincrnicas.

Enestecaso,AleenviarunmensajeaBparasolicitareliniciodelatarea,conlos
parmetrosquenecesite,yluegocontinuarsuflujodeejecucin.YentantoB,cuando
tengaelresultadolatarealisto,dealgunaformacomunicaraAdeestesuceso.Algunas
formasdehacerloson5:
depositarelresultadodelaoperacinenalgnlugardememoriacompartida,elcual
Aperidicamenterevisa
guardarunareferenciaaA,yenviarunmensajeastecuandohayaterminado
4
5

Locualrequerirmuchasvecesreintentarlaoperacin
Verelapuntedepatronesdecomunicacinentrecomponentes

6de18

Diseodeinterfacesentrecomponentes

guardaruncallback

Ejemplo:podemosconstruirunainterfazasincrnicaparanuestrocotizadordela
siguienteforma:

1. EnunprimeromomentoelcomponenteAdisparaelmensaje
cotizador.obtenerCotizacion()
2. ...pasaeltiempo,yelcotizador(componenteB)ponelarespuestaenelcotizador
cotizador.setUltimaCotizacion(cotizacion)
3. Mstarde,elcomponenteAirabuscarlarespuestaacotizador.ultimaCotizacion

Otambinpodramosusarcallbacks(bloquesdecdigo):

cotizador.obtenerCotizacion(\resultado -> ..usar resultado...)

YluegoBseencargardeejecutarelcallbackcuandoseanecesario.

Comocasoextremos,podradarsequeaAnoleimportaraqueBrealmenteleresponda
algo,sinotansoloqueseveanotificado.Enestecaso,Aslosedebeenviarleunmensaje
aBconlainformacinquenecesite,sinpreocuparseporcapturarunresultado.

Unainterfazsincrnicaquenoexponeunresultado,esmsfcilmenteconvertibleauna
interfazasincrnicaqueunaquesexponeunresultado.

4.2.1 Buffers

Muchasveces,parapoderlidiarconelasincronismoyelhechodequeAnoprocesar
instantneamenteelresultadodeB,oqueBnoiniciarinstantneamentelatareasolicitada
porA,esquenecesitaremosunbufferquealmacenetemporalmenteelresultadoy/o
parmetrosdelatarea.

SibienestebufferpuedeserunapartedelcomponenteBynomereceunestudioaparte,
otrasvecesestebufferesexterno,ytantoAcomoBdebernempezarahablarconbuffer,
enlugardeentreellos.

7de18

Diseodeinterfacesentrecomponentes

1. A
envaelmensajealbuffer(enlugardeenvirseloa
B
)
2. Unprocesotomalainformacindelbuffer,
a. envaunmensajea
B
b. ylarespuestadeesemensajeseenvaaA.

DesdelaperspectivadeA,necesitamosunainterfazentrantepararecibirelresultado,conlo
cualloqueanteserauncasodeusoahorasondos:
elpedidodeunaaccinaB
el procesamiento de la respuesta de B ante ese pedido, donde se acepta orechaza
latransaccin.

DesdelaperspectivadeBtenemosvariasopciones:
si el buffer tiene cierta inteligencia, entonces B no se ve afectado por el mecanismo
sincrnico / asincrnico de la interfaz: sigue siendo una interfaz entrante y no hay
muchoscambiosenlaimplementacin.
si por el contrario B toma la responsabilidad de avisar el resultado a A, la interfaz
entrante disparar a su vez una interfaz saliente con resultado ok o error una vez
procesadoelpedido.Estoseveenlafigurasiguiente:

8de18

Diseodeinterfacesentrecomponentes

5 Algunas palabras sobre las Fachadas (Faades)

Existe un patrn conocido como Faade cuya motivacin es proveer una abstraccin que
permiteveraunconjuntodeobjetoscomosifueranunosolo.

Poresosesueleutilizar
enalgunoscasos
paramodelarinterfacesentrantes.

Ejemplo
: tenemos un sistema de pedidos. Cada pedido tiene lneas o tems (
x cantidad de
producto
y
), un criterio que define la urgencia y cuidado de los productos que conformanel
pedidoyunestadoquedefinequhacerantedeterminadasacciones.

Paragenerarunpedido,
a. quieroagregar5kilosdequesoparmesano,2kilosdedulcedebatata
9de18

Diseodeinterfacesentrecomponentes

b. tambinquieroasignarleelestado(porejemplo,defaultenpendiente)
c. ysetearleeltipodepedido.

SipensamosmtodosenPedidoparafacilitarestastareas:

a. paraagregaruntem

public
voidaddItem(
intcantidad, Producto producto) {
this
.items.add(
newItem(cantidad, producto);
}

b. paraasignarestadodefault:

publicPedido() {
...
this
.estado =
newPendiente();
}

c. paraseteareltipodepedido

public
voidsetTipoPedidoMaximaSeguridad() {
this
.tipoPedido =
newMaximaSeguridad();
}

Entonces el Pedido est actuando como un Faade: el que genera un pedido nuevo no
necesitaconocerlostems,nilassubclasesdeestadonilassubclasesdeltipodepedido.

10de18

Diseodeinterfacesentrecomponentes

El Faade me permite tener un punto de acceso desde el cual ofrecer servicios a

componentes externos. Eso permite a losdemshablarconunnicocomponentenuestro y
eliminalanecesidaddeconocernuestromodelo.

5.1 Advertencias sobre el Faade

No obstante no es necesario tener siempre un objeto que oficie de fachada,
enespecialsi
lo nico que hace es redirigir el mensaje al objetodenegocioquehaceeltrabajoque
corresponde
.

Ejemplo
:enlainactivacinapareceunobjetoInactivacionFaade

QuhaceelmtodoinactivardeInactivacionFaade?

public
voidinactivar(Cliente cliente) {
cliente.inactivar();
}

Noagreganingnvalor,solamenteforwardeaelpedidoalcliente.

Adems, si elobjetivodelFaadeesverunconjuntodeobjetoscomosifueranunosoloeso
noseestcumpliendo:estamosrecibiendounobjetoclientecomoparmetro

public
voidinactivar(
Cliente cliente
){
cliente.inactivar();
}

Entonces si el que invoca a InactivacionFaade tiene que obtener de alguna manera al

cliente,lapreguntaes:porqunoleenvaelmensajeinactivar()directamentealcliente?

Corolario
: solamente usar Faade cuando usamos un objeto que simplifica la interaccin
con un mdulo de un sistema quepuedeserbastantecomplejo (comoenelcasodePedido
quepermitecentralizarlasaccionessobrelosdemsobjetosquemanejansuestado).

Corolario 2:
En el comn de los casos la interfaz entrante se modela con unmensajeaun
objetodenegocioyconesonosalcanza.

5.2 Malos usos del Faade

Suele ser un error comn del diseador novato confundir al Faade con un Manager, que
quieresuplantaralobjetodedominiotomandodecisionesquenosonpropias:

>>InactivarFaade

11de18

Diseodeinterfacesentrecomponentes

public
voidinactivar(Cliente cliente) {
cliente.setEstado(
"I"
);
}

Si el Faade toma decisiones que deberan estar en cliente (o enproductooen documento

de compra), es seal de que estamos yendo hacia un mal diseo: el cliente se vuelve una
estructuradedatospasivasobrelacualotrosobjetosmodificansuestadointerno.

La inactivacin en s misma no es un God Object, pero s la suma de los objetos

estereotipados como <<procesos>>. El resultado es un diseo pobre que no se parece en
nada a las ideas de objetos:cualquiercambioenlaestructuradeClienterepercuteentodos
losobjetosquehacenlasacciones.

6 Ejercicio prctico: compra con tarjeta de crdito

Ahoraveremoscmomodelarunainterfazatravsdeunejemploconcreto

Tenemosunsistemadeventasdeuncomerciocualquieraquetienecuentacorrientecon
susclientes.Necesitamosquecadaventaqueserealicecontarjetadecrditonotifiqueal
sistemaCreditSysteminformando:

Nmerodetarjetadecrdito
Montodelaventa
Descripcindelaoperacin
Comercioorigen
Fechayhora

Tenemosunbosquejodeldiagramadeclases:

12de18

Diseodeinterfacesentrecomponentes

No nos importa cmo se termina de resolver el mtodo comprar, slo nos interesa agregar
una responsabilidad ms: disparar la interfaz saliente contra el sistema de Tarjeta de
Crdito.

6.1 Interfaz saliente

Doscosasalrespecto:
1. Estbuenollevaresaresponsabilidadaunobjetoaparte
2. Por otra parte, aun si quisiera poner toda la responsabilidad en Cliente, cmo me
comunico con Credit System? No sabemos cmo implementar esa interfaz: el
enunciadonodicenadaalrespecto.

Yenrealidadnodicenadaporquenoesrelevanteparaestamateria.

Podemospensarmuchassolucionestcnicas:
RPC(RemoteProcedureCall)
Socketpuro
WebService

Cualquiera sea la tecnologa que elijamos, podemos abstraer la ideadenotificar lacompra

deunclientequetienetarjetadecrdito.

Sabemosqueunaabstraccinpuedeimplementarseenobjetosdemuchasmaneras:
Conunobjeto
Conunaclase
Conunainterfaz(ladeJava)
Conunmtodo
Conunmensaje
etc.

En nuestro caso, podemos pensar enunainterfazdeJavaparamodelarlanotificacindela

compra (interfaz saliente entre componente A, nuestra aplicacin y componente B, una
aplicacinespecficaparaTarjetasdeCrdito):

Este objeto S ser de una clase que implemente la interfaz que estamos definiendo ahora.
13de18

Diseodeinterfacesentrecomponentes

Lo importante es que yo no necesite cambiar la firma del mtodo cuando tenga que
implementarlacomunicacinposta.

Algunasopcionesposiblesparadefinirlainterfaz:
a. notificarCompra(Integer numeroTarjeta, BigDecimal monto, String operacion,
String CUITComercioOrigen, Date fechaCompra)

b. notificarCompra(Cliente cliente, Producto producto, String operacion, String

CUITComercioOrigen, Date fechaCompra)

c. notificarCompra(Compra compra)

a) soporta menos cambios en la interfaz que b): si enalgnmomentonospidenque

enviemos la razn social del cliente eso nos fuerzaacambiarlafirmadelmtodode
a).
Tanto a comobproponenuncontratocon5parmetros!,proponeruna
abstraccin
que relacione los elementos que intervienen en la compra es una tcnica apropiada
para reducir el impacto de cualquier cambio futuro (la heurstica nos dice que hay
altas chances de que un mtodo que recibe 5 parmetros sufra algunamodificacin
en el futuro cercano). Esta abstraccin puede incluso ser til para el negocio, como
enelcasodelaCompra.

Endefinitiva,loimportantees:
reconocerquenecesitamosponerlaresponsabilidadenunainterfazy
saberquinformacinvaanecesitarelquetermineimplementandoesainterfaz

El
contrato (la definicin del mensaje con los parmetros)
es lo que se pide en la
materia.

14de18

Diseodeinterfacesentrecomponentes

Yeldiagramadeclasesqueda:

TODO:Cambiarlafirmadelmtodo

sinnecesidaddedeterminarlaimplementacindedichainterfaz.

6.1.1 Cmo queda la compra en el cdigo

Una opcin posible es acceder al sistema Credit System desde un nico punto de acceso
global(
Singleton
).

>>Cliente
public
voidcomprar(Producto producto) {
...
if(
this
.tieneTarjetaDeCredito()) {
TarjetaCreditoPosta.getInstance().notificarCompra(
this
,
"Compra xx"
, Comercio.CUIT_Origen,
newDate());
}
...
}

producto,

15de18

Diseodeinterfacesentrecomponentes

Otra opcin es tener conjunto de interesados (

observers
,
listeners
) que implementan la
interfazsaliente:

>>Cliente
public

void
comprar(Productoproducto){
...
for
(ICompraObservercompraObserver:
this
.comprasObservers){
compraObserver.notificarCompra(
this
,producto,
"Compraxx"
,
Comercio.CUIT_Origen,
new
Date())
}
...
}

Ambas opciones son vlidas, aunque es importante recalcar que si nuestra intencin es
nicamente disparar una interfaz saliente y no nos interesa poder activar o desactivar esa
interfaz, el Observer es un caso de sobrediseo: nuestra solucin provee una complejidad
mucho mayor al problema que quiere resolver. Por otra parte s es correcto que pensemos
en el Observer cuando en el evento que activa la notificacin a esa interfaz saliente hay
otrosinteresadosoexisteesaposibilidad.

6.1.2 Manejo de Errores en la interfaz

Qusucedesitenemosquemanejarerroresalllamaralainterfaz?

Si seguimos pensando dentro del paradigma de objetos, los errores los manejamos con
excepcionesynoconcdigosderetorno.

Entonces preferimos pensar en notificarCompra como void, y no como un int

notificarCompra.

Querrorespodemosrecibir?
Errores en la conexin con el hostremoto,errorenla comunicacin(ruidoocortede
conexin),erroresdepermisoenelacceso,erroresenelformatodelmensaje,etc.
Erroresdeprogramaalejecutarelprocesamientodelmensaje
Errores denegocio:Elclientenoexiste,Elmontono puedesuperarlos$1.000 por
operacin,etc.

Los dos primeros son errores de sistema/programa. En el ltimo caso tenemos errores de
16de18

Diseodeinterfacesentrecomponentes

negocio. Dependiendo de cada caso quizs tengamos que contemplar acciones posibles o
simplementemostrarelmensajedeerrorenlapantalla(interfazdeusuario).

Si la tecnologa que usamos para comunicar

Acon
Bnotienemecanismodeexcepcionesy
nos devuelve un cdigo de error, es en definitiva problema de quien implemente la interfaz
ITarjetaCredito lo ideal es convertir ese cdigo de error 30018 en una excepcinquesea
lanzada para quien pueda atraparla correctamente (en muy pocos casos un objeto de
negocioyenlamayoradelasvecesunaventanadeusuario).

Entonces la implementacin posta de la tarjeta de crdito acta como un objetowrapper

queenvuelvelallamadareal(queretornaelint)yloconvierteenunaexcepcin:
>>Implementacin de la tarjeta de crdito
public
voidnotificarCompra(...) {
...
int codigoError = ...<conectarse mediante alguna tecnologaconelsistemade
tarjeta de crdito> ...;
if(codigoError == 30018) {
throw

newSystemException(
"... <formato del mensaje con error> ..."
)
;
}
if(codigoError == 30015) {
throw

new BusinessException(
"El monto no puede superar los $ 1.000 por
operacin"
)
;
}
...
}

6.2 Interfaz entrante

Enelmismosistemaqueremosmodelarlainactivacindeuncliente,quepuededispararse:
a. Desdelainterfazdeusuariodenuestraaplicacin

b. Desde el sistema de anlisis crediticio Customer Checker, un enlatado que no

formapartedenuestraaplicacin

Losclientesinactivosnopuedenhacercompras.

Estamosmodelandoahoraunainterfazentrantecombinandodosescenariosposibles:
17de18

Diseodeinterfacesentrecomponentes

Para el caso a): un mdulo que reside en el mismo ambiente del negocio (o no,
dependiendodequtecnologaelijamosparadesarrollarlainterfazdeusuario)
Parab):uncomponenteexterno

Quin es responsable de inactivar un cliente? El cliente, por supuesto, respondiendo al

mensajeinactivar():

Alosfinesprcticosdeesteapuntenoimportamucho
cmosecodificaelmtodoinactivar()
quvalidacinhayqueagregaralmtodocomprar()

sabemosquehabrunimpactoenesosmtodosynosalcanzaconeso.

6.2.1 Cmo definir la interfaz entrante

Para modelar una interfaz entrante basta con definir qu objeto de negocio es el que
responde a ese pedido: la tecnologa har la magia de convertir ese pedido en unmensaje
paradichoobjeto.

Nro.cliente

Fecha

Activar/Inactivar

102875

10/11/2009

18de18