Diapositivas 2013

ContenidoGral.
delCurso
ConceptosbsicosdeOrientacinaObjetos
AnlisisOrientadoaObjetos:
Modeladodeldominio
Comportamientodelsistema
Curso2013 DiseoOrientadoaObjetos:
Diseodeinteracciones
Diseodeestructura
ImplementacinOrientadaaObjetos:
Codificacin
Programacin4Curso2013 2
AsignaturasPosteriores Bibliografa
TallerdeProgramacin: ApplyingUMLandpatternsCraigLarman PrenticeHall(2Ed.2001)
ISBN9780130925695.Nota:estelibroutilizaunaversin1.xde
Semestre6
UML
IngenieradeSoftware: UMLDistilledMartinFowlerAddisonWesley(3Ed.2003)ISBN978
Semestre7 0321193681.Nota:estelibroutilizalaversin2.0deUML
DesignPatternsErichGamma,RichardHelm,RalphJohnson,John
ProyectodeIngenieradeSoftware: VlissidesAddisonWesley(1995)ISBN0201633612
Semestre8 CmoprogramarenC/C++H.M.DeitelyP.J.DeitelPrenticeHall
(1995)ISBN9688804711
BasesdeDatos,TalleresdeSistemasdeInformacin
(TSI) ParaverlaBibliografaComplementariaascomolarelacin
TemasCaptulosverlaWebdelcurso.
Programacin4Curso2013 3 Programacin4Curso2013 4
ProcesodeDesarrollo
Ques?
Unprocesodedesarrollodesoftwaredescribeun
enfoqueparaconstruir,instalarymantenersistemas
desoftware
DesarrolloOrientadoaObjetos Porqunecesitamosuno?
Esnecesarioconocerdeantemanoquactividades
basadoenUML debemosrealizar
Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 2
AlgunasActividades Pero Hay Ms

1. Entrarencontextoconlarealidaddelproblema
Realizarestimacionesdetiempo,decostos,de
2. Obtenerunadescripcindeloqueseesperadel recursos
producto Planificar
3. Comprenderqusedebehacer Asegurarsequelascosassehagan:
4. Determinarcmosedebehacer Eneltiempoprevisto
5. Hacerlo Delaformaestablecida
Administrarlasdiferentesversionesdeloqueseva
6. Probarqueestbienhecho produciendo
7. Entregarelproducto Montarymantener losambientesdedesarrolloy
8. Hacerleretoquesvarios prueba
9. Mantenerlo
Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 3 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 4
UnModelodeProceso Problemas
Cascada:
Cadaactividadserealizaensecuenciayluegode
Relevamiento
finalizarlaanterior
Anlisis
Paraproblemasgrandesycomplejosnoresultauna
Diseo estrategiaadecuada:
Erroresenetapastempranassedescubren
Implementacin
tardamente
Testeo Nohayvisibilidadhastamuyavanzadoelproyecto
Liberacin
Mantenimiento
OtroModelo Caractersticas
IterativoeIncremental(I&I): Sedivideelproblemaenvariossubproblemas
Las iteraciones se producen en Construccin
Se itera sobre una mini cascada donde se resuelve
Relevamiento
cadasubproblema:
for each (sp:Subproblema) {
analisis(sp);
diseo(sp);
Construccin implementacion(sp);
testeo(sp);
}
Liberacin Enlaiteraciniseresuelvespillevndoseresueltos
lossubproblemas:sp1,sp2, , spi-1
Mantenimiento

NuestroProceso NuestroProceso(2)
ParapoderrealizarunprocesoI&Iesnecesario LosrequerimientosvendrndadosporCasosdeUsoy
conocerunprocesoencascada descripcionesgeneralesdelsistema
Nosconcentraremosenalgunasactividadesdentro UnCasodeUsonarralahistoriacompleta(juntoatodas
de la cascada de Construccin: susvariantes)deunconjuntodeactoresmientrasusanel
Anlisis sistema
Diseo
Implementacin
Lospasosconcretosarealizarenestasactividades
dependedelparadigmadedesarrolloaseguir
CasodeEstudio CasodeUso
GestindecuentasenbancosatravsdeATMs(cajeros
automticos):
AtravsdeunareddeATMs,losclientesaccedenasus Nombre AgregarCancin Actor Usuario
cuentassobrelascualesrealizantransacciones Sinopsis Elcasodeusocomienzacuandoelusuarionecesitaagregaruna
nuevacancinalsistema.Paraelloespecificasuttuloyelaoen
(depsitosyretiros)
quesecompuso.LuegoElsistemamuestraunalistaconlos
Lascuentaspuedensercompartidaspormsdeun GnerosyotraconlosArtistasyelusuarioseleccionacules
cliente agregaalacancin.Finalmentesi lainformacinescorrecta,seda
dealtalacancinenelsistema

OrientacinaObjetos EnfoqueTradicional
Enfoquediferentealtradicional Unaaplicacinimplementadaconunenfoque
Puedeserentendidacomo: tradicionalpresentalasiguienteestructurageneral:
Unaformadepensarbasadaenabstraccionesde type T =
conceptosexistentesenelmundoreal
Organizarelsoftwarecomounacolaboracinde f1(T t) {}
objetosqueinteractanentrespormediode
fn() {}
mensajes
main() {
//invocaciones a fi
}
EnfoqueOrientadoaObjetos DesarrolloOO
Unaaplicacinorientadaaobjetoseselresultadode Lospasosgeneralesdedesarrollosemantienenenel
lacodificacinenunlenguajedeprogramacin enfoqueorientadoaobjetos
orientadoaobjetosdelsiguienteesquema: Perolasactividadesqueconstituyenalgunosdeellosson
particulares:
m m1 m3
o1 AnlisisAnlisisOrientadoaObjetos
o2 o3
DiseoDiseoOrientadoaObjetos
m2 ImplementacinImplemenentacinOrientadaaObjetos
o4 m4
o5

DesarrolloOO(2) DesarrolloOO(3)
Esnecesariaunaherramienta(conceptual)que
permitaalavez:
Ciertasactividadessondemasiadocomplejaspara Servirdeayudaparaeldesarrollodelatarea(uno
realizarlasmentalmenteeneldesarrollodeuna mismo)
aplicacindemedianoporteenadelante Visualizarlohechohastaelmomento(unomismo)
Comunicarelavanceobtenido(elclienteyelequipode
desarrollo)
Documentareldesarrollodelaaplicacin(elequipode
desarrollo)
DesarrolloOO(4) AnlisisOrientadoaObjetos
UMLeselestndarparamodeladodesoftware Considerareldominiodelaaplicacinysusolucin
lgicaentrminosdeconceptos(cosas,entidades)
Esunlenguajequepuedeseraplicadocualquierasea
elmtodoparticulardedesarrollarsoftware Conceptoclave:abstraccin
orientadoaobjetos Objetivo:encontrarydescribirlosconceptosenel
Utilizaremosalgunosdesusdiagramasparaasistir dominiodelaaplicacin:
nuestrodesarrollo Estopermitecomprendermejorlarealidadyel
problema

AnlisisOrientadoaObjetos(2) AnlisisOrientadoaObjetos(3)
Estosconceptospuedenentendersecomouna
primeraaproximacinalasolucinalproblema Realidad Dodge Viper
Rivera 9332
Enunsistemadesoftwareorientadoaobjetos(bien John Walker
modelado)existeunisomorfismoentreestos
conceptosyloselementosqueparticipanenel
problemaenlavidareal
Modelo Auto
Casa
Persona
AnlisisOO::Actividades
AnlisisOO::Dominio
ModeladodeDominio UnModelodeDominiocontienelosconceptosysus
Modelareldominioparacomprendermejorelcontexto relacionesqueseansignificativoseneldominiodel
delproblema
problema
Herramienta:DiagramadeClases
LainformacinesprovistaprincipalmenteporlosCasos
EspecificacindelComportamiento
deUso
contarconunadescripcinmsprecisadequesloque
seesperadelsistema Seincluyenademslasrestriccionesalascualesest
Herramientas:DiagramasdeSecuenciadelSistemay sujetoeldominio
Contratos

ModelodeDominio AnlisisOO::Comportamiento
LosDiagramasdeSecuenciadelSistemailustranla
forma en que los actores realizan invocaciones sobre
elsistema
Losdiferentesescenariosdeusosonlosdefinidosenlos
CasosdeUso
Elefectodecadamensajeesespecificadoenforma
precisapormediodeunContrato
Diagramadesecuencia(DSS) CasodeEstudio
Contrato
Operacin ingresarCancion(titulo:string, ao: int)
Comienzaelingresodeunanuevacancinalsistemaespecificando
Descripcin
lainformacinbsica
Pre- 1.Noexisteunacancindenombreigualatitulo
condiciones 2.Elparmetroaonoesmayoralaoactual
Post- Elsistemarecuerdaeltituloyelaoespecificados,parausarse
condiciones posteriormente.

DiseoOrientadoaObjetos(2)
DiseoOrientadoaObjetos
Objetivo:definirobjetoslgicos(desoftware)yla Conceptoclave:responsabilidades
formadecomunicacinentreellosparauna
posteriorprogramacin Enestatransicin:
Notodoslosconceptosnecesariamenteparticiparnde
En base a los conceptos candidatos encontrados
lasolucin
duranteelanlisisypormediodeciertos
principiosytcnicas,sedebedecidir: Puede ser necesario reflotar conceptos inicialmente
dejadosdelado
Culesdestossernlosobjetosqueparticiparnenla
solucin Ser necesario fabricar ayudantes (tambin objetos)
Cmosecomunicanentreellosparaobtenerel paraquelosobjetospuedanllevaracabosutarea
resultadodeseado
DiseoOO::Actividades
DiseoOO::Interacciones
DiseodeInteracciones
definircmosecomunicanlosobjetospararesolverlas SerealizaunDiagramadeComunicacinpor
operacionesdelsistema operacindelsistema
Herramienta:DiagramadeComunicacin Los objetos protagonistas aparecen sugeridos en el
DiseodeEstructura ModelodeDominio
especificarlaestructuranecesariaparaquetodaslas Elresultadoesperadoeselespecificadoenel
interaccionespuedanocurrir contratodelaoperacinadisear
Herramienta:DiagramadeClasesdeDiseo

DiagramasdeComunicacin DiseoOO::Estructura
SeresumelainformacinprovistaporlosDiagramas
deComunicacin
LaestructuraestguiadaporelModelodeDominio
GeneralmenteserealizaunnicoDiagramadeClases
queresumetodalainformacin
DiagramadeClasesdeDiseo
ImplementacinOO
Suobjetivoescodificarenunlenguajede
programacinorientadoaobjetoslasconstrucciones
definidaseneldiseo
Ladefinicindelosobjetosyelintercambiode
mensajesrequierenconstruccionesparticularesenel
lenguajeautilizar

Resumen
Message1
: Sistema Object1 Object2

: Cajero
iniciarVenta()
agregarProducto(id,cant)
Cont.1 Message2
Object3
descripcion, subtotal
* [mas productos] Message1

terminarVenta()
Object1 Object2
total con impuestos
realizarPago(monto)
Cont.2 Message2
Object3
cambio, recibo
Esc. Tpico
: Sistema
: Cajero
Esc. Alternat. 1
iniciarVenta()
Cont.1
CasosdeUso .
.
* [mas productos]
terminarVenta()
Message1
.
total con impuestos
realizarPago(monto) Object1 Object2
cambio, recibo
Cont.3
Esc. Alternat. n
Message2
Object3
: Sistema
: Cajero
iniciarVenta()
* *
Association1 Class4
Cont.1
ConceptosBsicosdeOrientacina
Class1 descripcion, subtotal
-atr3
-atr1 * [mas productos]
-atr4 terminarVenta()
total con impuestos

*
* Association2
realizarPago(monto) Message1
Class2 Class3
Cont.4
cambio, recibo
Object1 Object2
-atr2
Message2
Object3
Objetos(1eraparte)
Class4
Class1 * Association1 * -atr3
-atr1 -atr4
+operacion1()
+oper1()
+operacion2()
+oper5()
*
Class2 Class3 * Association2
-atr2
+oper2() +oper4()
+oper3()
Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 37
Contenido
ConstruccionesBsicas
Relaciones
Despacho
Programacin4Curso2013 ConceptosBsicos(1eraparte) 2
CasodeEstudio CasodeEstudio(2)
Caso:UsuariocreaCancionesenlabibliotecade
msica
Responsabilidad:Crearlacancinen labibliotecay
asociarlacorrectamenteconelrestoconlosgneros
yartistascorrespondientes
Programacin4Curso2013 ConceptosBsicos(1eraparte) 4 Programacin4Curso2013 ConceptosBsicos(1eraparte) 5
Objeto Identidad
Unobjetoesunaentidaddiscretaconlmitese
identidadbiendefinidos Esunapropiedadinherentedelosobjetosdeser
distinguibledetodoslosdems
Encapsulaestadoycomportamiento:
Dosobjetossondistintosaunquetenganexactamente

Objeto Variable Tradicional losmismosvaloresensuspropiedades

C C Conceptualmenteunobjetononecesitadeningn
mecanismoparaidentificarse
E C vs. E C
C C Laidentidadpuedeserrealizadamediantedirecciones
dememoriaoclaves(peroformandopartedela
Esunainstanciadeunaclase infraestructurasubyacentedeloslenguajes)

Clase Clase(2)
Unaclaseesundescriptordeobjetosque Definicin de una clase
compartenlosmismosatributos,operaciones,
mtodos,relacionesycomportamiento class Cancion {
... // definicion de
Unaclaserepresentaunconceptoenelsistema
... // los atributos /
queseestmodelando
... // operaciones
Dependiendodelmodeloenelqueaparezca, };
puedeserunconceptodelmundoreal(modelo
deanlisis)opuedeserunaentidaddesoftware Instancia de una clase (i.e. un objeto)
(modelodediseo) Cancion *c = new Cancion();
delete c;
Clase(3) Atributo
Esunadescripcindeuncompartimientodeuntipo
Paracrearunobjetosedefinenconstructores
//por defecto (sin parmetros) especificadodentrodeunaclase

Cancion::Cancion () Puedeser:

//comn (con parmetros)
Cancion::Cancion(string titulo, int anio) DeInstancia:Cadaobjetodeesaclasemantieneun

//por copia valordeesetipoenformaindependiente

Cancion::Cancion(Cancion &) DeClase:Todoslosobjetosdeesaclasecompartenun
mismovalordeesetipo
Paradestruirunobjetosedefineundestructor
Cancion::~Cancion();

Atributo(2) Operacin
class Genero {
Esunaespecificacindeunatransformacino
private:
string nombre; // Atributo de instancia consultaqueunobjetopuedeserllamadoaejecutar
static string MAX_LARGO; // Atributo de clase Tieneasociadaunnombre,unalistadeparmetrosy
} untipoderetorno
Clase Genero
g1
g2
nombre=Pop C MAX_LARGO=50
nombre=House C
C
Mtodo OperacinyMtodo
class Genero {
Eslaimplementacindeunaoperacinparauna private:
determinadaclase string nombre;
public: Operacin
Especificaelalgoritmooprocedimientoquegenerael
resultadooefectodelaoperacin string getNombre();
};
string Genero::getNombre(){
return "el genero es" + nombre;
}
Mtodo para getNombre() en Genero

Estado Comportamiento
Elestadodeunainstanciaalmacenalosefectosdelas
Eselefectoobservabledeunaoperacin,incluyendo
operaciones
suresultado
Estimplementadopor
Suconjuntodeatributos
Suconjuntodelinks
Eselvalordetodoslosatributosylinksdeunobjeto
enuninstantedado
AccesoaPropiedades AccesoaPropiedades(2)
Losatributosdeberanserprivadosylas
Laspropiedadesdeunaclasetienenaplicadas operacionespblicas:
class Genero {
calificadoresdeacceso private:
EnC++unapropiedaddeunobjetocalificadacon: string nombre;
public:puedeseraccedidadesdecualquierpuntodesde public:
elcualsetengavisibilidadsobreelobjeto string getNombre();
};
private:puedeseraccedidasolamentedesdelos
string Genero::getNombre() {
mtodosdelapropiaclase return nombre;
protected:enC++permitevisibilidadalaclaseysu }
derivada Genero *g = ;
// cdigo no vlido fuera de la clase
Otroslenguajespuedendefinirdiferentestiposde g->nombre
acceso // cdigo vlido
c->getNombre()
DataType DataType(2)
Esundescriptordeunconjuntodevaloresque Muchoslenguajesdeprogramacinnotienenuna
carecendeidentidad construccinespecficaparadatatypes
Datatypespuedensertiposprimitivospredefinidos Enesoscasosseimplementancomoclases:
como: Susinstanciasseranformalmenteobjetos
Strings
Nmeros
Fechas
Tambintiposdefinidosporelusuario,como
enumerados
DataType(3) DataValue
class Complejo { Esunvalornicoquecarecedeidentidad,una
private: instanciadeundatatype
float i, j; Undatavaluenopuedecambiarsuestado:
public:
Esoquieredecirquetodaslasoperacionesaplicables
Complejo (int i, int j);
Complejo operator+ (Complejo &); son funciones puras (sin efectos secundarios) o
// ... ... consultas
}; Losdatavaluessonusadostpicamentecomovalores
deatributos
Complejo operator -(Complejo i, Complejo d);
Para que sea un datatype, las operaciones no pueden modificar

el estado interno del objeto sino retornar uno nuevo
ValoresyCambiosdeEstado
IdentidadonoIdentidad
El valor 4 no puede ser convertido en el valor Cmosabersiunelementotieneonoidentidad?:
5 Dosobjetosseparadosqueseanidnticoslucen
igualesperonosonlomismo(sondistinguiblespor
Se le aplica la operacin suma con argumento 1 suidentidad)
yelresultadoeselvalor 5 Dosdatavaluesseparadosqueseanidnticosson
consideradoslomismo(nosondistinguiblesporno
Aunobjetopersonaselepuedecambiarlaedad: teneridentidad)
Reemplazando el valor de su atributo edad por otro
valornuevo
Elresultadoeslamismapersonaconotraedad
Asociacin
Unaasociacindescribeunarelacinsemnticaentre
clasificadores(clasesodatatypes)
Lasinstanciasdeunaasociacin(links)sonel
conjuntodetuplasquerelacionanlasinstanciasde
dichosclasificadores
Cadatuplapuedeaparecercomomximounasola
vezenelconjunto
Asociacin(2) Link
Unaasociacinentreclasesindicaquees Esunatupladereferenciasainstancias(objetoso
posible conectar entre s instancias de dichas datavalues)
clases
Esunainstanciadeunaasociacin
Cuandosedeseapoderconectarobjetosde
Permitevisibilidadentretodoslasinstancias
ciertasclases,stasdebenestarrelacionadas
participantes
porunaasociacin

UnaasociacinRentreclasesAyBpuede
entendersecomoRAB
Loselementosen Rpuedenvariarconeltiempo
RepresentacindeAsociaciones
Link(2)
Ejemplo:asociacinRentreclasesAyB Casiningnlenguajeproveeconstrucciones
R={<a1,b1>,<a1,b2>,<a2,b3>} especficasparaimplementarasociaciones
Para ello se suelen introducir pseudoatributos
enlasclasesinvolucradas
Objetos de clase A Objetos de clase B
Deestamaneraunlinknoresultaimplementado
a1 b1
exactamenteigualasurepresentacinconceptual
Unatuplaesdivididayuncomponenteesubicado
a2 b2 enelobjetoreferenciadoporelotrocomponente
a3 b3 delatupla
b4

RepresentacindeAsocs.(2) RepresentacindeAsocs.(3)
e1 e2 Ejemplo:AsociacinentreClienteyTransaccion
Representacin class Genero {
conceptual E C E C
private:
string nombre; // atributo
Vector<Cancion> canciones;// pseudoatributo
...
};
e1 e2 Eltipodeunpseudoatributosueleserunaclase,pero
Implementacin
usual eldeunatributodebeserundatatype
psatr1 psatr2
C C Porcuestionesdecostosiunadelasvisibilidadesnoes
necesariausualmentenoseimplementa
Generalizacin Taxonoma
Unageneralizacinesunarelacintaxonmicaentre
unelemento(clase,datatype,interfaz)msgeneraly
+ general Animales
entreunelementomsespecfico
Elelementomsespecficoesconsistente(tiene
Vertebrados Invertebrados
todassuspropiedadesyrelaciones)conelms
general,ypuedecontenerinformacinadicional
Reptiles Peces Mamferos Aves Moluscos Equinodermos
Placentarios Marsupiales
+ especfico

ClaseBaseyClaseDerivada ClaseBaseyClaseDerivada(2)
Cuandodosclasesestnrelacionadassegnuna Unaclasepuedetenercualquiercantidaddeclases
generalizacin,alaclasemsgeneralseladenomina base,ytambincualquiercantidaddeclases
clasebaseyalamsespecficaclasederivadadela derivadas.
msgeneral class Artista {
...
Aunaclasebaseseladenominatambinsuperclaseo
};
padre
Aunaclasederivadaseladenominatambinsubclase class Solista: public Artista {
...
ohijo };
class Banda: public Artista{

...
};
AncestrosyDescendientes(2)
AncestrosyDescendientes Animales
Losancestrosdeunaclasesonsuspadres(siexisten),
juntoconlosancestrosdestos
Vertebrados Invertebrados
Losdescendientesdeunaclasesonsushijos(si
existen),juntoconlosdescendientesdestos Reptiles Peces Mamferos Aves Moluscos Equinodermos
Unaclaseesclasebasedirectadesushijos,yuna
claseesclasederivadadirectadesuspadres Placentarios Marsupiales
Unaclaseesclasebaseindirectadelosdescendientes
desushijos,yunaclaseesclasederivadaindirectade Ancestros de Marsupiales son {Mamferos, Vertebrados, Animales}
Descendientes de Invertebrados son {Moluscos, Equinodermos}
losancestrosdesuspadres Ave es clase derivada directa de Vertebrados e indirecta de Animales
Vertebrados es clase base directa de Mamferos e indirecta de Marsupiales

Subclassing Subsumption
Sedefinelarelacinentreclases: Esunapropiedadquedebencumplirtodoslosobjetos,
(<:)contenidoenClaseClase tambinconocidacomointercambiabilidad
donde, Unobjetodeclasebasepuedesersustituidoporun
B<:ABesclasederivadadeA objetodeclasederivada(directaoindirecta)
Porlotanto: : , <: :
Observacin:Larelacin<:defineunordenparcial Esto se puede leer como: un objeto instancia de una
entreclases. clasederivadaestambininstanciadecualquierclase
base
Ejemplo: Todo Entero es un Real
Herencia Herencia(2)
Eselmecanismoporelcualsepermite
compartirpropiedadesentreunaclaseysus Sedicequelaclaseheredalaspropiedades
descendientes especificadasporsusancestros
Siunaclasenotieneningnpadreentoncessus Entonceslalosatributosyoperacionesdeuna
propiedadessonlasdefinidasenlamismaclase. clasesonlosquedeclaramslosdesuclasebase
Sitienepadre,entoncessuspropiedadessonlas
delaunindelaspropiasjuntoconlasdesu Sepuededecirqueunaclasederivadaextiendea
padre suclasebase.

Herencia(3) Polimorfismo
Class Artista {
private: string nombre; Eslacapacidaddeasociardiferentes
public: string getNombre();
}; mtodosalamismaoperacin
string Artista::getNombre(){
No alcanza con que tengan el mismo nombre, para ser
return nombre; polimorfismo deben ser realmente la misma operacin!
}
class Solista: public Artista { class A { class B {

public: string toString(); void oper() { void oper() {
}; // un mtodo // otro mtodo
} }
string Solista::toString (){ } }
return "Solista: nombre=" + getNombre();
} En este caso no se trata de la misma operacin (aunque tengan la
misma firma) dado que las dos clases no estn relacionadas entre s
RedefinicindeOperaciones RedefinicindeOperaciones(2)
class Artista {
Artista
private: string nombre;
Cuandoenunajerarquadegeneralizacionesse public: virtual string toString(); ATTArtista::nombre
encuentramsdeunmtodoasociadoala };
OpArtista::toString()
string Artista::toString(){
mismaoperacin,sedicequedichaoperacin return nombre; METArtista::toString()
estredefinida }
Paraunaclasedeterminada,elmtodoasociado class Banda: public Artista { Banda

private: Fecha *fundacion;
adichaoperacinseraquelqueseencuentre public: virtual string toString(); ATTArtista::nombre
msprximoenlajerarqua }; ATTBanda::fundacion
string Banda::toString(){
return "Banda ->" + Artista::toString(); OpArtista::toString()
} METArtista::toString()
METBanda::toString()

RedefinicindeOperaciones(3)
Sobrecarga
ParalaclaseBandaelmtodoasociadoatoString()es Eslacapacidadquetieneunlenguajedepermitir
eldelaclaseBanda(ocultandoalheredadodesdela quevariasoperacionestenganelmismonombre
claseArtista,parausosdesdefueradelaclase)
sintctico,perorecibiendodiferente
ATTArtista::nombre, cantidad/tipodeparmetros
ATTBanda::fundacion
Ejemplosdesobrecarga:
OpArtista::toString()
string Banda::toString()
METArtista::toString(), METBanda::toString() String Banda::toString(bool conFundacion)
Elmtodoheredadopuedeserreferenciadoenla Lasobrecarganoesunconceptoexclusivodela
claseBandausandosufirmacompleta( orientacinaobjetos
Artista::toString())
Sobrecargavs.Redefinicin OperacinAbstracta
Laredefinicintratadelamismaoperacin,con Enunaclase,unaoperacinesabstractasinotiene
diferentesmtodos unmtodoasociado
Lasobrecargatratadediferentesoperaciones, Tenerunaoperacinabstractaescondicin
condiferentesmtodos suficienteparaqueunaclaseseaabstracta
Unaclasepuedeserabstractaansintener
operacionesabstractas

OperacinAbstracta(2)
class Numero {
// operacin sin mtodo (abstracta)
OperacinAbstracta(3)
public: virtual float tofloat() = 0; ClaseLista
};
Gracias a la herencia
OPLista::tamanio()
class Racional : public Numero { es posible que una
private: int numerador, denominador;
public: float toFloat ();
operacin est en OPLista::getElemento(int indice)
}; ms de una clase
float Racional::toFloat(){ ClaseArreglo
if(denominador == 0) return NAN;
else return numerador / (float) denominador; ATTArreglo::tam
}
ATTArreglo::elementos
class Entero: public Numero { Gracias al polimorfismo
private: int valor; OPLista::tamanio()
es posible asociarle
public: float toFloat ();
} mtodos diferentes en METArreglo::tamanio()
cada una de ellas
float Entero::toFloat(){
return (float) valor;
OPLista::getElemento(int indice)
} METArreglo::getElemento(int indice)
ClaseAbstracta(2)
ClaseAbstracta class Lista {
public:
virtual int tamanio() = 0;
Algunasclasespuedenserabstractas: virtual string getElemento(int idx) = 0;
};
Ningnobjetopuedesercreadodirectamenteapartir Observacin:
deellas class Arreglo { Lista es una clase
private: abstracta por tener
Nosoninstanciables int tam; una operacin
string *elementos;
Lasclasesabstractasexistensolamenteparaque public: abstracta.
int tamanio(); Debido a esto, toda
otrasheredenlaspropiedadesdeclaradasporellas string getElemento(int idx); instancia concreta
}; de Lista es un
int Arreglo::tamanio(){
return tam; Arreglo
}
string Arreglo::getElemento(int idx){
return elementos[idx];
}
InstanciaDirectaeIndirecta
SiunobjetoescreadoparaunaciertaclaseC,
entoncessedicequeeseobjetoesinstanciadirecta
deC
Ademssedicequeelobjetoesinstanciaindirecta
detodaslasclasesancestrasdeC
Ejemplo:
Arreglo *a = new Arreglo();
aesinstanciadirectadeArreglo
aesinstanciaindirectadeLista(ysusancestros,sitiene)
Invocacin Despacho
Conlaintroduccindesubsumptionesnecesario
Unainvocacinseproducealaccederauna reexaminarelsignificadodelainvocacinde
propiedaddeunainstanciaqueseaunaoperacin operaciones
Elresultadoeslaejecucindelmtodoquelaclase Suponiendob:ByB<:Aesnecesariodeterminarel
dedichainstancialeasociaalaoperacinaccedida significadodeb.f()cuandoByAasocianmtodos
(despacho) distintosalaoperacinf()
Portratarsedeb:Bresultaranaturalqueelmtodo
despachadoporlainvocacinseaeldelaclaseB
Sinembargoporsubsumptiontambinb:A,porlo
queseraposiblequeelmtodoadespacharseael
delaclaseA
Despacho(2) Referencia
Enestetipodecasoslodeseableesqueelmtodoa Unareferenciaesunvalorentiempodeejecucin
despacharseaelasociadoalaclasedelacualel quees:voidattached
objetoalqueleesaplicadalaoperacinesinstancia
Siesattachedlareferenciaidentificaaunnico
directa
objeto(sedicequelareferenciaestadjuntaaese
Enelejemploanterior,B
objetoparticular)
Siemprequeesposibleeldespachoserealizaen
Siesvoidlareferencianoidentificaaningnobjeto
tiempodecompilacindenominndosedespacho
esttico
Referencia(2) TipoEstticoyDinmico
Cancion *c1 = null; // void Eltipoestticodeunobjetoeseltipodelcualfue
Cancion *c2 = new Cancion(lazy song, 2012); // attached declaradalareferenciaadjuntaal:
Cancion *c3 = *c2; // attached
Seconoceentiempodecompilacin
Eltipodinmicodeunobjetoeseltipodelcuales
titulo=lazysong
ao=2012 instanciadirecta
Enciertassituacionesambostiposcoincidenporlo
getTitulo() quepierdeelsentidorealizartaldistincin
getAo()
c1 c2
c3
TipoEstticoyDinmico(2) TipoEstticoyDinmico(3)
Numero *x = new Racional(1,2);
Ensituacionesespeciales,eltipodinmicodifiere
deltipoestticoyseconoceentiempode TipoEstatico(t) = Numero
ejecucin TipoDinamico(t) = Racional
Estetipodesituacinesenlaquelareferenciaa bool esRacional;
// el usuario ingresa en la consola 1 o 0
unobjetoesdeclaradacomodeunaclase cout << "Quiere un numero racional? ";
ancestradeltipodelobjeto: cin >> esRacional;
Locualespermitidoporsubsumption Numero *x;
if (esRacional)
Secumplelasiguienterelacinentrelostiposde x = new Racional(1,3);
obj: else
TipoDinamico(obj)<:TipoEstatico(obj) x = new Entero(432);
Cul es el tipo dinmico de x?
DespachoDinmico DespachoDinmico(2)
Loslenguajesdeprogramacinorientadosa Derealizarseeldespachoenformaestticase
objetospermitenqueeltipodinmicodeun utilizaraparaellolanicainformacindisponible
objetodifieradeltipoesttico delenesemomento:
Cuandoserealizaunainvocacinaunaoperacin Labasadaeneltipoesttico
polimrfica(queestredefinida)sobreunobjeto Porloquesedespachara(eventualmente)el
utilizandounareferenciaaldeclaradacomode mtodoequivocado:
unadesusclasesancestraspuedenosercorrecto Enparticular,cuandolaoperacininvocadaes
realizareldespachoentiempodecompilacin abstractaenlaclasedeltipoestticonohaymtodo
quedespachar

DespachoDinmico(3) DespachoDinmico(4)
Numero *x;
if (esRacional) Paraqueenestetipodecasoseldespachosea
x = new Racional(1,3); realizadoenformacorrectaesnecesarioesperar
else
Laoperacin acontarconlainformacindeltiporealdel
toFloat() x = new Entero(432);
declaradaenNumero objeto(tipodinmico):
espolimrficaporquees x->toFloat();
redefinidaenEnteroyen Esoseobtieneentiempodeejecucin
Racional
Seestinvocandoauna Eldespachodinmicoeslacapacidaddeaplicar
operacinpolimrficasobreunobjeto(queserdeclaseEntero
Racional)medianteunareferenciadeclaradacomodetipoNumero(clase unmtodobasndoseenlainformacindinmica
ancestradelasanteriores)
EnestainvocacindeberadespacharseMETEntero::toFloat()METRacional::toFloat() delobjetoynoenlainformacinestticadela
referenciaal
DespachoDinmico(5)
Numero *x; DespachoDinmico(6)
if (esRacional) Ladecisindequtipodedespachoemplearparauna
x = new Racional(1,3); operacinpuedeestarpreestablecidaenelpropiolenguaje
else odefinidaestticamenteenelcdigofuente
x = new Entero(432); Enalgunoslenguajesdeprogramacineldespachoes
dinmicoparacualquieroperacin(seapolimrficaono)
x->toFloat();
Enotroslenguajes:
Entiempodecompilacin:alpasarporlainvocacinel Lasinvocacionesaoperacionespolimrficassonsiempre
compiladorNOdespachamtodoalguno despachadasdinmicamente
Entiempodeejecucin:alpasarporlainvocacinelambiente
Lasinvocacionesaoperacionesnopolimrficassonsiempre
deejecucindellenguajeseocupadeaveriguareltipo
despachadasestticamente
dinmicodeeydespacharalmtodocorrecto,esdecira:
METRacional::toFloat()oMETEntero::toFloat()

DespachoDinmico(7) DespachoDinmico(8)
Numero *arr[3]; Sloserealizasilaoperacinestdefinidacomovirtual
arr[0] = new Racional(1,2); Siesasintentadespacharelmtododefinidoeneltipo
arr[1] = new Entero(2);
arr[2] = new Racional(1,4); dinmico
Encaso deque nohaya unmtodo all,busca elprimer
float total = 0.0;
for(int i = 0; i < 3; i++){
mtodoenlajerarquahaciaarriba
total += (arr[i])->toFloat();
}
cout << "El total es" << total; Despacha dinmicamente al

mtodo correcto, devolviendo
el valor correcto
AlgoritmodedespachoC++(simplificado)
DespachoDinmico(9) Elcompiladorbuscalaoperacinsegneltipoesttico.
Sevadirectamentealaclasedeltipoesttico,aldesupadre,luego
aldesuabuelo,yassucesivamentehastaencontrarlaoperacin
class Natural: public Entero {
queseinvoca.
// no define float toFloat();
}; a) Silaoperacinencontradanoesvirtual
Sedespachaelmtododelaclasequelodeclar(despachoesttico)
Numero *arr[3]; b) Silaoperacinencontradaesvirtual
arr[0] = new Racional(1,2); Sedespachaelmtododinmicamentesegneltipodinmico
arr[1] = new Entero(2); (despachodinmico)
arr[2] = new Natural(3); Sevadirectamentealaclasedeltipodinmico(entiempode
ejecucin)ysinohayunmtodoparaesaoperacinsebuscaenel
arr[0]->toFloat(); // Despacha el mtodo de Racional padre,abuelo,etc.hastaencontrarunaclasequedefinaunmtodo
arr[1]->toFloat(); // Despacha el mtodo de Entero paralaoperacin.
arr[2]->toFloat(); // Despacha el mtodo de Entero
Obs: Una operacin es virtual si tiene el calificador virtual en la declaracin o si alguna
clasebasedirectaoindirectadeclaralamismaoperacinconelcalificadorvirtual.
Contenido
EspecificacindeRequerimientos
TiposdeRequerimientos
RequerimientosFuncionales
RequerimientosdeSoftware CasosdeUso
Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 2
EspecificacindeRequerimientos EspecificacindeReq.(2)
LaEspecificacindeRequerimientosesuninsumo
fundamentaleneldesarrollodesoftware: Representa un contrato con el usuario
Eslaprincipalfuentedeinformacinapartirdelacualse
disea,implementaytesteaelsistema Nosegeneraporcompletoaliniciodelproyecto,sino
Esunodelosaspectosmsdelicadosdeunproyecto:
incrementalmente
Esalgocomplejodeobtener Suelepresentarsecomolaagregacindediferentes
Desucorrectituddependeelxitodelproyecto artefactos
Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 3 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 4

RequerimientosNoFuncionales
TiposdeRequerimientos
Unrequerimientoesunacondicinocapacidad Losrequerimientosnofuncionalessuelenreferira:
queunsistemadebecumplir Usabilidad:factoreshumanos,ayuda,documentacin
RequerimientoFuncional: Confiabilidad:frecuenciadefallas,tiempode
Expresaunaaccinquedebesercapazderealizarel recuperacin
sistema
Performance:tiempoderespuesta,tasade
Especificacomportamientodeentrada/salida
procesamiento,precisin,capacidaddecarga
RequerimientoNoFuncional:
Soportabilidad:adaptabilidad,mantenibilidad,
Expresaunapropiedadocualidadqueelsistemadebe
presentar configurabilidad,internacionalizacin
Tambinrestriccionesfsicassobrelosfuncionales
RequerimientosNoFuncionales
RequerimientosFuncionales
yms: Losrequerimientosfuncionalesseexpresabanen
Interfaces:restriccionesenlacomunicacinconsistemas
trminos de funciones del sistema
externos Unafuncindelsistemaesalgopuntualqueel
Restricciones:enelusode sistemadebehacer
Sistemasopaquetesexistentes Tcnicabsica:SiXesunafuncindelsistema,
Plataformas entonceslafraseEl sistema debe hacer Xtiene
Lenguajesdeprogramacin quetenersentido
Ambientesdedesarrollo
Herramientas(sistemasdebasesdedatos,middleware,etc.)

RequerimientosFuncionales(2)
CasosdeUso
Estaherramientafuncionbienmientras: Elenfoquedecasosdeusoestbasadoenla
Lasfuncionalidadesdelossistemaseransencillas nocindeactor
Elmodelodeusodelosusuariosselimitabaauna Unactoresunagenteexterno(humanoono)
interaccinsimpleypuntualconelsistema queinteractadirectamenteconelsistema
Perdisuefectividadcuandolasinteraccionesa Uncasodeusonarralahistoriacompleta(junto
soportarsevolvieronmscomplejastomando atodassusvariantes)deunconjuntodeactores
mientrasusanelsistema:
perodosdetiempomsprolongados
Lahistoriaterminacuandounodelosactores(el
Nuevoenfoque:CasosdeUso principal)lograsuobjetivoyobtieneunresultadode
valor
CasosdeUso(2) CasosdeUso(3)
Loscasosdeuso(ysimilares)sonunaherramienta Uncasodeusosecomponede:
muyaplicadaparalaespecificacinde
Nombrequeidentificaalcasodeuso
requerimientosfuncionales
Actoresparticipantesenelcasodeuso
Porserexpresadostextualmenteresultansimples
Sinopsisquedescribebrevementesuobjetivo
decomprender(hastaparapersonalnotcnico)
Cursotpicodeeventosque narra la historia mscomn
Porestarorientadosalosobjetivosdelosactores
delosactoresduranteelusodelsistema
(yalcaminohaciasuobtencin):
Cursosalternativosdeeventosquenarranlasvariantesde
Sonintuitivos
usodelsistema
Propicianlacompletituddeespecificacin

CasosdeUso(4) CasosdeUso(5)
Loscasosdeusonosuelenespecificarsecontododetallede Mtodobsico(variablesegnelavance):
unasolavez
1. Detectar actores
Estoserealizaenformagradualyposteriorala
identificacindeactores: 2. Identificar algunos casos de uso
(detectando objetivos y necesidades de actores)
Losactoressonmsfcilesdeidentificarysusnecesidadessonlasque 3. Especificarlos en alto nivel
danlugaraloscasosdeuso 4. Examinarlos y expandir algunos de ellos
Formasposiblesdeuncasodeuso: 5.
Identificadoodetectado:solosunombreyactoresparticipantes
Especificadoenaltonivel:seincorporaunasinopsis
Amedidaqueseavanzaeneldesarrollose
Especificado en forma expandida: se incorpora la historia de uso y
detectannuevoscasosdeusoyseespecificanotros
susvariantes yadetectados
Ejemplo(AltoNivel)
CasosdeUso(6)
Sobreelprincipiodelproyectosetiendeabuscary Nombre EscribirEmail
especificarloscasosdeusomsimportantes Actor Usuario
Loscasosdeusoseusanademscomocriteriode Descripcin El caso de uso comienza cuando el Usuario desea escribir un
correo electrnico. Para ello especifica el cuerpo del correo
particindelproblemaenunprocesoiterativoe electrnico y un asunto. Luego si lo desea el usuario puede
incremental: adjuntar uno o ms archivos de su disco duro en el email. Al
finalizar de escribir el email el sistema especifica una lista de
En una iteracin se desarrolla uno a la vez contactos y el usuario selecciona opcionalmente uno o ms
destinatarios. Para cada destinatario puede especificar que tipo
Los incrementos no refieren a partes fsicas sino a dedestinatariosetrata(Principal,ConCopiaoConCopiaoculta).
conjuntosdefuncionalidades Luego el usuario puede elegir ms destinatarios escribiendo
manualmentesuscorreoselectrnicosyeltipodedestinatarioal
igualquelohizoantes.Alfinalizarelsistemaenvaelcorreoylo
copiaenlacarpetaEnviados.
Ejemplo(Expandido) Qusiguedespus?
CasodeUso:EscribirEmail
Actores:Cliente Unavezdetectadoyespecificadoelconjunto
Sinopsis:ElcasodeusocomienzacuandoelUsuario
deseaescribiruncorreoelectrnico.Paraello[] inicialdecasosdeuso:
EscenarioTpico:
1. UsuarioespecificaCuerpodelcorreoyelasunto
2. ElSistemamuestraunalistadecontactos Elequipodedesarrolloestlistoparaanalizarlos,
3. ElUsuarioseleccionacontactosyespecificaparacadaunoel disearunasolucinparaelloseimplementarlos
tipodedestinatario
4. ElUsuarioespecificamsdestinatariosescribiendosusnombres
yeltipodedestinatario
5. ElUsuariohaceclickenunbotnEnviar Mientrastantoelequipodeanalistasavanzaenla
6. ElSistemaenvaelmail
7. ElSistemacopiaelmailalacarpetaEnviados
deteccinyespecificacindeotroscasosdeuso
Objetivos
Modelareldominiodelproblema:
Paracomprendermejorelcontextodelproblema
Paraobtenerunaprimeraaproximacinalaestructurade
lasolucin
Especificarelcomportamientodelsistema:
Paracontarconunadescripcinmsprecisadequeslo
queseesperadelsistema
Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 20
Actividades ModeladodelDominio
Paralograrlosobjetivosplanteadosrealizaremoslas Consisteenencontrarydescribirlosconceptosenel
siguientesactividades: dominiodelaaplicacin
ModeladodelDominio Duranteestaactividadseconstruyeel
EspecificacindelComportamientodelSistema ModelodeDominio
Enlseincluyentodosloselementosquesedefinan
duranteestaactividad
ComportamientodelSistema
Consisteen:
Entendercadacasodeusoentrminosdeintercambiosde
mensajesentrelosactoresyelsistema
Especificarelcomportamientodecadaunodeesos
mensajes(perosindecircmofuncionan)
Programacin 4
DuranteestaactividadsecompletaelModelodeCasos CASO DE ESTUDIO :: ANLISIS
deUso
Enlseincluyentodosloselementosquesedefinan
O BJETIVO
duranteestaactividad En este documento se presenta un caso de estudio que servir como gua prctica para la introduccin de la
etapa de anlisis, tanto para las actividades de Modelado de Dominio como de Especificacin del
Comportamiento del Sistema.
DESCRIPCIN DE LA REALIDAD
Se desea construir una aplicacin web que permita la reserva y venta de pasajes de avin. La aplicacin
debe manejar informacin de las personas que realizan las reservas y compran los pasajes. De cada persona
se sabe su nombre (que lo identifica), telfono y edad. Las mismas pueden reservar o comprar mltiples
Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis pasajes, pero para eso
23 deben ser mayores de 18 aos. Las personas deben primero reservar pasajes y en ese
caso se registra la fecha de reserva y el costo de la misma en dicho momento.
Cuando la persona compra la reserva queda responsable de realizar el pago, sea en efectivo o con tarjeta de
crdito. En caso de pagar en efectivo, se aplica un descuento porcentual que es el mismo para todos los
pagos en efectivo. En caso contrario es necesario registrar el nmero de la tarjeta y la cantidad de pagos que
se realizarn.
MODELADO DE DOMINIO ESPECIFICACIN DEL COMPORTAMIENTO DEL SISTEMA
Un posible modelo para la realidad planteada es el siguiente. A continuacin se presentan dos casos de uso del sistema junto con sus respectivos Diagramas de
Secuencia del Sistema y algunos de los contratos de las operaciones involucradas. En los casos de uso se
puede apreciar a dos actores diferentes: el Cliente que interacta con el sistema para la reserva y compra de
pasajes, y el Administrador encargado de las tareas de mantenimiento.
Nota: Los Diagramas de Secuencia del Sistema (DSS) son una extensin de los Diagramas de Secuencia de
UML en donde aparecen los actores enviando mensajes al sistema. Dado que no son parte del estndar,
muchas de las herramientas de modelado no permiten modelar a los actores, salvo mediante un objeto que
lo represente. No obstante, para nuestros propsitos esto ser suficiente.
Alta de Vuelo
Nombre Alta de Vuelo

Actores Administrador
Descripcin El caso de uso comienza con el Administrador que solicita al Sistema la creacin de un
nuevo vuelo indicando los aeropuertos de origen y destino del mismo, as como la fecha
de realizacin del vuelo. El Sistema da de alta al vuelo y retorna un cdigo
autogenerado que identifica al mismo. A continuacin, el Administrador solicita al
Algunos comentarios sobre el modelo:
Sistema que asigne un avin al vuelo recientemente creado indicndole la matrcula del
La asociacin entre Pasaje y AsientoVuelo representa la ocupacin del Vuelo, es decir, si existe un
avin. El Sistema relaciona el vuelo con el avin y con ello define los asientos que
link entre dos instancias de estas clases indica que el asiento correspondiente est ocupado para ese
estarn disponibles para reservar.
vuelo.
En tanto un pasaje no se compre no habr un link entre Pasaje y Pago
El DSS correspondiente al caso de uso anterior se muestra a continuacin. Notar que en l mismo, el
En caso de querer manejar un costo de asientos variable a lo largo del tiempo y no perder los costos
Sistema NO TIENE MEMORIA. Esto se ve reflejado por la necesidad de indicar en el segundo mensaje el
con los cuales se compr un pasaje, es necesario realizar la siguiente modificacin en el modelo. La
cdigo del vuelo dado de alta a consecuencia del primer mensaje.
nueva clase Costo es la que debera asociarse con Pasaje en lugar de la clase AsientoVuelo.
Algunas de las restricciones presentes en el modelo son las siguientes: Los contratos de las operaciones correspondientes a los mensajes del DSS anterior son los siguientes.
El nombre de una persona la identifica (unicidad de atributos)
La edad de una persona debe ser mayor o igual a 18 (dominio de atributos) Operacin nuevoVuelo(ae1:string, ae2:string, fecha:Date):int
Los asientos asignados al vuelo que realiza un avin son asientos de ese avin (integridad circular) Descripcin Da de alta un nuevo vuelo
El costo de un pasaje es la suma de los montos de las instancias de AsientoVuelo asociadas menos el Pre y postcondiciones
descuento correspondiente (atributos calculados) Pre: Existe una instancia de Aeropuerto con atributo codigo = ae1
Si un pasaje tiene ms de tres instancias de AsientoVuelo asociadas y el pasaje fue comprado y pago
con tarjeta, entonces al costo se le aplica el descuento de pago en efectivo (regla de negocio) Pre: Existe una instancia de Aeropuerto con atributo codigo = ae2
Post: Se cre una instancia de Vuelo con atributo fecha = fecha y atributo codigo autogenerado
por el sistema
Post: Se cre un link entre la instancia de Vuelo y la instancia de Aeropuerto con atributo codigo =
ae1 con rol origen
Post: Se cre un link entre la instancia de Vuelo y la instancia de Aeropuerto con atributo codigo =
ae2 con rol destino
Programacin 4 Curso 2013 Caso de Estudio - Anlisis 2 Programacin 4 Curso 2013 Caso de Estudio - Anlisis 3
Post: Se retorn el atributo codigo de la instancia de Vuelo creada El DSS correspondiente al caso de uso anterior se muestra a continuacin. Notar que en l mismo, el
Sistema TIENE MEMORIA. Esto se ve reflejado en los comentarios.
Operacin asignarAvion(codVuelo:int, matricula:string)
Descripcin Asigna un avin a un vuelo
Pre y postcondiciones
Pre: Existe una instancia de Vuelo con atributo codigo = codVuelo
Pre: Existe una instancia de Avion con atributo matricula = matricula
Pre: No existe un link entre la instancia de Vuelo y la de Avion
Post: Se cre un link entre la instancia de Vuelo y la de Avion
Post: Para cada instancia de Asiento asociada a la instancia de Avion, se cre una instancia de la clase
de asociacin AsientoVuelo entre el Asiento y el Vuelo con atributo monto = 0
Reserva y Compra de Pasaje
Nombre Reserva y Compra de Pasaje

Actores Cliente
Descripcin El caso de uso comienza con el Cliente que solicita al Sistema el inicio de una reserva
indicndole su nombre (que ya est registrado en el Sistema). Luego el Cliente
comienza un ciclo de consulta de vuelos y reserva de los mismos. En primer lugar
consulta con el Sistema los vuelos definidos entre dos aeropuertos a partir de una fecha
dada y el Sistema le retorna la lista de cdigos de vuelo junto con la lista de asientos
disponibles para cada uno de ellos. En segundo lugar, opcionalmente, el Cliente reserva
un asiento para un vuelo determinado y el Sistema registra la reserva. Al finalizar este
ciclo el Cliente solicita al Sistema el costo final de la reserva realizada. Finalmente, el Los contratos de las operaciones correspondientes a los mensajes del DSS anterior son los siguientes.
Cliente le indica al Sistema si comprar el pasaje, ingresando en este caso si pagar con
tarjeta o en efectivo, o si cancelar la reserva. En el primer caso el Sistema retorna el Operacin iniciarReserva(nombre:string)
costo final a pagar por parte del Cliente. Descripcin Se inicia una reserva
Pre: Existe una Persona con atributo nombre = nombre
Post: Se crea una instancia de Pasaje con atributo fecha = hoy y se crea un link de la
asociacin reserva entre la instancia de Persona y la de Pasaje
Post: El sistema recuerda la instancia de Persona y la de Pasaje
Operacin consultarVuelo(ae1:string, ae2:string, fecha:Date):

List(DataVuelo)
Descripcin Se consulta la disponibilidad de vuelos
Pre: Existe una instancia de Aeropuerto con atributo cdigo = ae1
Pre: Existe una instancia de Aeropuerto con atributo cdigo = ae2
Post: Se devuelve una lista de tipo DataVuelo donde cada una representa informacin sobre las
instancias de Vuelo con atributo fecha >= fecha, con links a las instancias de Aeropuerto
anteriores con rol origen y destino, respectivamente. Cada DataVuelo contiene el valor del atributo
codigo de la instancia de Vuelo y la lista de valores de los atributos numero de las instancias de
Asiento asociadas y disponibles.
Programacin 4 Curso 2013 Caso de Estudio - Anlisis 4 Programacin 4 Curso 2013 Caso de Estudio - Anlisis 5
Pre: No existe un link de la asociacin compra entre la instancia de Persona recordada por el sistema
Operacin reservarAsiento(codVuelo:int, asiento:int) y la instancia de Pasaje
Descripcin Se reserva un asiento para un vuelo determinado
Pre: No existe un link entre la instancia de Pasaje y una instancia de Pago
Post: Se crea un link de la asociacin compra entre la instancia de Persona recordada por el sistema y
Pre: Existe una instancia de Pasaje recordada por el sistema la instancia de Pasaje
Pre: Existe una instancia de Vuelo con atributo cdigo = codVuelo Post: Se crea una instancia de Tarjeta con atributo estado = pendiente, atributo numero =
Pre: Existe una instancia de Asiento con atributo numero = asiento asociada a la instancia de numTar y atributo cantPagos = pagos y se crea un link entre dicha instancia y la instancia de
Vuelo Pasaje
Pre: No existe un link entre la instancia de AsientoVuelo, asociada a las instancias de Vuelo y Post: Se devuelve la suma de los valores del atributo monto de las instancias de AsientoVuelo
Asiento, y una instancia de Pasaje. (el asiento est disponible) asociadas a la instancia de Pasaje
Pre: El sistema recuerda menos de cinco instancias de AsientoVuelo
Operacin cancelarReserva()
Post: Se crea un link entre la instancia de Pasaje recordada por el sistema y la instancia de
AsientoVuelo Descripcin Se cancela la reserva realizada
Operacin consultarCosto():float Pre: El sistema recuerda una instancia de Persona y una de Pasaje asociada a entre dos y cinco
Descripcin Se consulta el costo final del pasaje reservado sin los descuentos instancias de AsientoVuelo
Pre y postcondiciones Post: Se elimina la instancia de Pasaje y los links entre sta y las instancias de Persona y
Pre: Existe una instancia de Pasaje recordada por el sistema AsientoVuelo recordadas por el sistema
Post: Se devuelve la suma de los valores del atributo monto de las instancias de AsientoVuelo Post: El sistema deja de recordar informacin
asociadas a la instancia de Pasaje
Operacin comprarPasajeEfectivo():float
Descripcin Se ingresa la responsabilidad de pago en efectivo
Pre: El sistema recuerda una instancia de Persona y una de Pasaje asociada a entre dos y cinco
instancias de AsientoVuelo
Pre: No existe un link de la asociacin compra entre la instancia de Persona recordada por el sistema
y la instancia de Pasaje
Pre: No existe un link entre la instancia de Pasaje y una instancia de Pago
Post: Se crea un link de la asociacin compra entre la instancia de Persona recordada por el sistema y
la instancia de Pasaje
Post: Se crea una instancia de Efectivo con atributo estado = pendiente y se crea un link entre
dicha instancia y la instancia de Pasaje
Post: Se devuelve la suma de los valores del atributo monto de las instancias de AsientoVuelo
asociadas a la instancia de Pasaje con el descuento correspondiente al atributo descuento de
Efectivo
Operacin comprarPasajeTarjeta(numTar:int, pagos:int):float

Descripcin Se ingresa la responsabilidad de pago con tarjeta
Pre: El sistema recuerda una instancia de Persona y una de Pasaje asociada a entre dos y cinco
instancias de AsientoVuelo
Contenido
Programacin 4 Curso 2013 Caso de Estudio - Anlisis 6 Programacin 4 Curso 2013 Caso de Estudio - Anlisis
Introduccin 7
ModelodeDominio
Conceptos
Asociaciones
Anlisis Atributos
ModeladodelDominio Generalizaciones
Otroselementos
Restricciones
Programacin4Curso2013 Anlisis ModeladodelDo

Introduccin
Laesenciadelanlisisorientadoaobjetosesla
descomposicindelproblemaenconceptosindividuales
UnModelodeDominiocontieneprincipalmentelos
conceptosysusrelacionesqueseansignificativosenel
dominiodelproblema:
Significativosparaelmodelador
Elproblemaylosrequerimientosdeterminanques
significativo
Programacin4Curso2013 AnlisisModeladodelDominio 3
ModelodeDominio ModelodeDominio(2)
Estenfocadoenconceptosdeldominioynoenentidades Contenido(cont.)
desoftware Relaciones:Relacionesdeasociacinogeneralizacinentre
Contenido: lasclasesquerepresentanconceptos
Introduccin:Brevedescripcinquesirvecomointroduccinal Restricciones:Expresionesquerestringen
modelo lasposiblesinstanciasdelosconceptosdelmodelo
Conceptos:Clasesquerepresentanconceptossignificativos Diagramas:Representaciones(usualmenteunosolo)de
presenteseneldominio conceptos,tiposyrelacionespresentesenelmodelo
Tipos:Datatypesquedescribenpropiedadesdelasclasesque
representanconceptos
Programacin4Curso2013 AnlisisModeladodelDominio 5 Programacin4Curso2013 Anlisis ModeladodelDominio 6

Conceptos Atributos
Unconceptoesunaidea,cosaoelementodela Esnecesarioidentificaraquellosatributosque
realidadoproblemaqueseestmodelando. permitansatisfacerlosrequerimientosde
Ejemplo: informacin
Unatributoseentiendecomoundatavaluede
unobjeto
Eltipodeunatributoesundatatype
Venta v1 : Venta
fecha
hora v2 : Venta
importe
Atributos Atributos
Notacin Notacin(2)
Almostrarunatributoesnecesarioespecificaralmenos Alcancedeatributos
sunombre
Propiedadesopcionales
Tipo,multiplicidad,valorinicial,visibilidad,etc. Empleado Empleado
sueldo sueldo
Persona Persona
nombre -nombre[1] : String De instancia De clase
telefono +telefono[*] : String
edad -edad[1] : Integer = 0
Representacin Representacin
mnima completa
Atributos Atributos
Notacin(3) Sugerencias
Unatributo(ocualquierelemento)queseaderivablese Noutilizaratributoscomoclavefornea
marca con un / Losatributosnodebenserutilizadospararelacionarelementos
Lousualesadjuntarleunanotaespecificandolaformaen delmodelo
quesecalcula
Avion Piloto
nombrePiloto nombre
Persona
edad = hoy - fechaNacim nombre
vs.
fechaNacim
/edad comanda
Avion Piloto
nombre
Atributos Conceptos
Sugerencias(2) IdentificacindeConceptos
Tiposprimitivosynoprimitivos Esmuycomnomitirconceptosenestafase
Lostiposdelosatributossonengeneraltiposprimitivos (identificacin)quepuedenserdescubiertosenunafaseo
(Integer,String,Real,etc.) etapaposterior
AldescubrirlosselosagregaalModelodeDominio
Desernecesarioesposibledefinirtiposnoprimitivosparaun
problema Esposibleencontrarconceptosinteresantesquenotengan
atributos(quetenganunroldecomportamientomsque
datatype
deinformacin)
Venta
Date
fecha:Date
1 datatype
Venta
Date
fecha
Conceptos Conceptos
IdentificacindeConceptos(2) IdentificacindeConceptos(3)
ComenzarlaconstruccindeunModelodeDominio Listadecategorasdeconceptos:
haciendounalistadeconceptoscandidatos Consisteenrepasarlalistadecategorasdeconceptos
Existendostcnicasparaello: buscandolosconceptosdeldominiodelproblemaque
Listadecategorasdeconceptos apliquenacadacategora
Identificacindesustantivos
Categora Ejemplo
Objetos fsicos o tangibles Avin
Descripciones de cosas DescripcionVuelo
Lugares Aeropuerto
Transacciones Reserva
Roles Piloto
Conceptos Conceptos
IdentificacindeConceptos(4) IdentificacindeConceptos(5)
Listadecategorasdeconceptos(cont.) Identificacindesustantivos
Lalistasepuedecontinuarcon:
Seidentificanlossustantivosdeunadescripcintextualdel
contenedoresdecosas
problema(visindelproblemay/ocasosdeuso)yselos
cosascontenidasencontenedores
consideracomoconceptosoatributoscandidatos
sistemasexternos
Noesposiblerealizarestaactividadenformatotalmente
sustantivosabstractos
organizaciones
automtica
Ellenguajenaturalesambiguo
eventos
Notodosustantivorefiereaunconceptosignificativo
reglasypolticas
catlogos
registrodeasuntosfinancierosolegales
servicioseinstrumentosfinancieros

Conceptos Conceptos
IdentificacindeConceptos(6) Sugerencias
Identificacindesustantivos(cont.) CmocrearunModelodeDominio:
Ejemplo: 1. Listarlosconceptoscandidatosusandocualquieradelasdos
tcnicaspresentadas(ounacombinacindeambas)
2. IncluirlosenelModelodeDominio
Un cliente llega a un puesto de venta para reservar
un pasaje de avin El empleado hace la reserva en
3. Agregarlasasociacionesnecesariaspararegistrarrelaciones
el sistema de aerolnea. quenecesitenserpreservadas
4. Agregarlosatributosnecesariosparasatisfacerlos
Consideramosestossustantivoscomolosprimeros requerimientosdeinformacin
candidatosparaserconceptos
Sugerencia: Generar y mantener el diagrama en paralelo

Conceptos
Conceptos
Sugerencias(2)
Sugerencias(3)
Nombresymodelado Granularidaddelaespecificacin
Laestrategiadelcartgrafoseaplicatantoala Duranteelprocesodemodelado,esmejorsobre
construccindemapasyaladeModelosdeDominio: especificarconmuchosconceptosdegranularidadfina,
Usarnombresqueexistanenelterritorio quesubespecificar
Excluircaractersticasirrelevantes Elcostodeeliminarunconceptoqueresultinnecesario
Noincluircosasinexistentes esmenorqueeldeagregarunoquefueomitido
Siempreesposibleagregaroeliminarconceptosdurante
elprocesodemodelado


Conceptos Conceptos
Sugerencias(4) Sugerencias(5)
Errorcomnalidentificarconceptos Errorcomnalidentificarconceptos(cont.)
ElerrormscomnalcrearunModelodeDominioes
representaralgocomounatributocuandodebiserun
concepto Vuelo
destino
SinosepiensaenunconceptoXbsicamentecomoun
nmero,untextoounbooleano(odatatypesengeneral)
entoncesXprobablementeseaunconcepto vs.
Encasodeduda,representarlocomounconcepto
finaliza en
Vuelo Aeropuerto
nombre
Conceptos Conceptos
Supngaselasiguientesituacin: Enelcasodequeunproductoseagotenadiepodr
Una instancia de Producto representa a un producto saberculeraelpreciodeeseproducto
fsicoenunatienda Esedatoestabaincluidoensolamenteenlas
Unproductotieneunnmerodeserie,unadescripcin,un instanciasqueconformabanelinventario
precioyuncdigo,quenoaparecenenningunaotraparte
Notartambinqueexisteinformacinrepetida
Los que trabajan en la tienda no tienen memoria
Cadavezqueunproductofsicoesvendido,la
correspondiente instancia de Producto es
eliminadadelsistema

Conceptos Conceptos
Especificacionesydescripciones: Especificacionesydescripciones(cont.)
Senecesitanconceptosqueseandescripcionesdeotros Ejemplo:
conceptos
Producto p1 : Producto p2 : Producto
Enelcasodelproductonecesitamosuna
numSerie numSerie = "40-51-2" numSerie = "40-51-4"
DescripcionProducto que registre la informacin de los descripcion descripcion = "Video..." descripcion = "Video..."
codigo
productos precio
codigo = "VCR99A"
precio = 270
codigo = "VCR99A"
precio = 270
Estosconceptosnorepresentanlosproductos,sino
informacinacercadeellos vs.
Si todas las instancias de Producto son eliminadas, la
p1:Producto
EspecificacionProducto permanece * 1 EspProducto
numSerie="40512" :EspProducto
Producto
descripcion descripcion="Video..."
numSerie codigo codigo="VCR99A"
precio p2:Producto
precio=270
numSerie="40514"
Asociaciones Asociaciones(2)
Esnecesarioidentificaraquellasasociacionesentre Sedistinguendoscategorasdeasociaciones:
conceptosque: Decomprensin:Permitencomprendermejorelproblema
Seannecesariasparasatisfacerlosrequerimientos Need-to-know:Permitensatisfacerlasrequerimientosde
deinformacin informacin
AyudenalacomprensindelModelodeDominio
Unaasociacinesunarelacinentreconceptosque
indicaalgunaconexininteresanteosignificativaentre
ellos
Engeneralsurgendelconocimientodeunarelacin
quedebeserpreservadaporunaciertotiempo

Asociaciones Asociaciones
DeteccindeAsociaciones
Listadecategorasdeasociacionescomunesque DeteccindeAsociaciones(2)
puedenresultardeutilidadalmomentoderealizarun Listadecategorasdeasociaciones(cont.)
ModelodeDominio Lalistasepuedecontinuarcon
AesunadescripcindeB
Categora Ejemplo AesuntemdeunatransaccinB
Aesconocido/registrado/capturadoenB
A es una parte fsica de B Ala - Avin AesunasubunidadorganizacionaldeB
A es una parte lgica de B Tramo - Ruta AusaomanejaB
A est contenido fsicamente en B Pasajero - Avion AsecomunicaconB
AestarelacionadoconlatransaccinB
A est contenido lgicamente en B Vuelo - PlanVuelo AesunatransaccinrelacionadaconlatransaccinB
A es un miembro de B Piloto - Aerolinea AestcercadeB
AespropiedaddeB
AsociacionesaConsiderar AsociacionesaConsiderar(2)
Considerarlainclusindelassiguientesasociaciones: Sugerencias
Asociacionesparalasqueelconocimientodelarelacin Concentrarseenidentificarconceptosmsque
debeserpreservadoporunaciertaduracin(needto asociaciones
know) Evitarmostrarasociacionesderivablesoredundantes
Asociaciones derivadas de la Lista de Asociaciones
Demasiadasasociacionestiendenaconfundirmsquea
Desernecesarioincluirasociacionesdecomprensin ilustrar

Asociaciones
Asociaciones Notacin
AsociacionesaConsiderar(3)
Ideal:puntointermedioentreunmodelominimal La asociacin se lee: A asociada a B
sloconasociacionesneedtoknowyotrocontodas direccin
lasasociacionesconcebibles nombre de lectura
multiplicidad
Criterio:quesatisfagatodoslosrequerimientosde
informacinyademspermitaunacomprensinde * asociada a 1
A B
losconceptosenelproblema
el equilibrio rol2 rol1
buscado
agregacin
slo todas las extremos de
need-to-know concebibles rol
asociacin
Asociaciones
Asociaciones NotacinMultiplicidades(2)
NotacinMultiplicidades
Lamultiplicidadlimitalacantidaddevecesque Seexpresacomounsubconjuntodelosnaturales
unainstanciadeterminadaestconectadaaotras (subrangooenumerado)
atravsdeunaasociacin mNtalquemax(m)>0
Esoseindicaenelextremodeasoc.opuesto asoc Ejemplos:
a1 b1 * Cualquiercantidad(cerooms)
asocAB Indica la cantidad de a1 b2 1..* Almenosuno(unooms)
instancias de B que pueden a2 b2
a3 b1 0..1 Opcionalmenteuno(ceroouno)
conectarse con un A cualquiera
a1 b3 5 Exactamentecinco
a2 b3
3,5,8 Exactamentetres,cincouocho
asoc m
A B

NotacinRoles NotacinRestricciones
Especificanelpapelquejueganlasclasesenuna Enocasionesesnecesarioespecificarqueexisteuna
asociacin restriccinentredosasociaciones
Puedensernecesariosparaeliminarambigedades Porejemplo,queunpardeinstanciassoloestn
dueo
conectadasmedianteunaasociacin
Persona Empresa
dueo
empleado Persona Empresa
{xor}
p1 : Persona
dueo
p1 es dueo o empleado
empleado de e? e : Empresa
Deestaformaunapersonanopuedeserdueoy
y p2? p2 : Persona empleadodelamismaempresa
empleado
NotacinRestricciones(2) NotacinRestricciones(3)
Otroejemplo,sidosinstanciasestnconectadaspor Esposibletambinindicarqueexisteunordenentre
unaasociacin,tambinlodebenestarporotra lasinstanciasconlascuales
asociacin otrainstanciaestrelacionada

dueo * *
Persona Empresa Curso
{ordered}
Alumno
{subset}

empleado
Deestaformaunapersonaqueseadueadela Aquinteresaelordendelosalumnosencadacurso
empresatienequeserempleado (porejemploporcdula)

NotacinAgregacin NotacinAgregacin
Agregacincompuesta
Esunaformamsfuertedeasociacin
Unelementoesexclusivodelcompuesto(mximodela
Significaqueunelementoespartedeotro multiplicidades1)
Existendosvariantes Generalmenteunaaccinsobreelcompuestosepropagaa
Agregacincompartida(agregacin) laspartes(tpicamenteenladestruccin)
Agregacincompuesta(composicin)
Agregacincompartida
Mano Dedo
Habitacion Pared 1 0..5
1..2 4
Generalizaciones
Generalizaciones Notacin
Esposibleespecificarvariantesdeunconceptocuando
abstracto concreto
Lossubtipospotencialesrepresentanvariantesinteresantes
deunciertoconcepto
Unsubtipoesconsistenteconsusupertipo(seaplica Evaluacion Curso
subsumption) fecha
Todoslossubtipostienenatributoscomunesquepuedenser
factorizadosenelsupertipo enumeration
Examen Parcial InstanciaParcial
Todoslossubtipostienenasociacionescomunesquepueden
minimo inst : InstanciaParcial unico
serfactorizadasenelsupertipo primero
segundo
enumerado
(data type)
Generalizaciones Generalizaciones
Sugerencias Sugerencias(2)
Modeladodeestados Modeladodeestados(cont.)
Modelarlosestadosdeunconceptosolamentecuando
resulteimprescindibleparacomprenderelproblema Lampara
NomodelarlosestadosdeunconceptoXcomosubtipos
deX Lampara
Paraestoutilizar encendida? : Boolean
Atributos Encendida Apagada
Conceptos (con cuidado)
Correcto Incorrecto
TiposAsociativos TiposAsociativos(2)
Untipoasociativoesunelementoqueestantoclase IncluirelsueldoenlaPersonanoescorrectoya
comoasociacin
queunaPersonapuedetenermsdeunsueldoy
Motivacinparausartiposasociativos
stedependedeltrabajo
Unaempresacontrataadiferentespersonasparatrabajary
acadaunaleasignaunsueldoparticular IncluirelsueldoenlaEmpresatampocoes
Unapersonapuedesercontratadapordiferentesempresas correctoyaquelaEmpresapagasueldosdistintos
ypuederecibirunsueldodiferenteporcadatrabajo
acadaempleado
Interesasabercuntocobraunapersonaencadatrabajo
Estoconducealanocindetiposasociativos,los
cualespermitenagregarpropiedadesalas
asociaciones
TiposAsociativos TiposAsociativos
Notacin ModeladoAvanzado
Cmosemodelacuandosenecesitanmltiplesinstancias
delamismaclasedeasociacinpara
* 1..* unmismopardeinstancias?
Empresa Persona
Ejemplo:registrartodoslossueldosdeunapersonadentro
deunaempresa
* 1..*
Empresa Persona
trabaja
sueldo
El tipo asociativo 1
permite Empresa-Persona
representar *
La relacin
multiplicidades
Empresa-Persona
y atributos Trabaja
acepta mltiples
-sueldo
trabajos
ModelodeDominio ModelodeDominio
ErroresComunes ErroresComunes(2)
Modelarunestadomedianteconceptos Omisindeunaespecificacinparalasinstancias
sinserestrictamentenecesario Incluirelementosdeldiseo(interfaces,dependencia,
Modelarelconceptomsgeneraldelproblemasinser etc.)
necesario Representarasociacionescomoatributos(usode
Modelarundatatypecomoconcepto clavesforneas)
yviceversa Redundanciaysobreespecificacin
Malusodelasclasesdeasociacin Especificareltipodeestructuraenunamultiplicidad
de*

Restricciones
EsmuycomnelhechodequeunModelodeDominio
noalcancearepresentarexactamentelarealidad
planteada
Existencasosdondeunmodelorepresentafielmentela
mayoradelosaspectosdelarealidadsinembargo
permiteotrosquenosondeseables
Programacin4Curso2013 Anlisis ModeladodelDominio 56
Restricciones Restricciones
Motivacin Motivacin(2)
Permite o considera como vlidos casos como:
Empresa trabajaen Vendedor
Un vendedor vende un producto producido
por una empresa para la cual l no trabaja
1 *
* * e1 : Empresa v1 : Vendedor
Todas las multiplicidades
estn satisfechas!
Producto
(esta configuracin de
produce } |vende objetos es vlida respecto
* 1 e2 : Empresa p1 : Producto al Modelo de Dominio)
El modelo representado por este

La empresa de v1 (o sea e1) debera producir el producto que
diagrama: Refleja fielmente la realidad? l vende (o sea p1), o v1 debera trabajar en la empresa e2
Motivacin(3) ModificardelModelo
Esmuycomnenfrentarseanteestetipodesituaciones Enmuchoscasosesposibleeliminarsituacionescomola
Existendosalternativasparasolucionarelproblema descritamedianteunamodificacinalmodelo
ModificarelModelodeDominioparaevitarque Escomnqueestamodificacinnoseamenorporloque
configuracionesnodeseadaspuedanservlidas esposibleque
Adjuntarrestriccionesalmodelotalesqueinvaliden
Insumademasiadotiempo
aquellasconfiguracionesnodeseadas
Laversinmodificadaseamuycomplicada
Laversinmodificadarestrinjaloscasosnodeseadospero
introduzcaotrosnuevos
AdjuntarRestricciones Invariantes
Otraalternativaalproblemaeslaimposicinde Losinvariantespuedenserexpresadosinformalmente
restricciones(enparticularinvariantes) enlenguajenatural
Uninvarianteesunpredicadoqueexpresauna Unejemplodeestopuedeser
condicinsobreloselementosdelModelodeDominioy
quesiempredebeserverdadero Invariante:
Cuandoesevaluadocontraunaciertaconfiguracinde
objetosdandounresultadodefalsosignificaquela Todo vendedor debe vender un producto que
configuracindeobjetosnoesvlida sea producido por la empresa para la cual trabaja
UMLnoespecificaelmodoenqueuninvariantedeba
serexpresado
Puedeutilizarsenotacininformaloformal

Restricciones
RestriccionesHabituales Ejemplos
UnicidaddeAtributos(IdentificacindeInstancias)
Unatributotieneunvalornicodentrodeluniversode trabajaen
Empresa Vendedor
instanciasdeunmismotipo(unainstanciaesidentificadapor Unicidad de Atributos
esevalor) /cantEmp edad
1 * (Invariante)
DominiodeAtributos * *
Elvalordeunatributoperteneceaciertodominio
No hay dos productos con
IntegridadCircular Producto
el mismo cdigo (el cdigo
Nopuedeexistircircularidadenlanavegacin produce } codigo |vende
* 1 identifica al producto)
AtributosCalculados
Elvalordeunatributoescalculadoapartirdelainformacin
contenidaeneldominio
ReglasdeNegocio
Invariantequerestringeeldominiodelproblema
Ejemplos(2) Ejemplos(3)
trabaja en
Empresa Vendedor trabaja en
/cantEmp edad
Dominio de Atributos Empresa Vendedor
Integridad Circular
1 1..* (Invariante) /cantEmp
1 1..*
edad
(Invariante)
1..* 1..*
1..* 1..*
En la empresa no puede Un vendedor no puede
Producto
haber vendedores mayores Producto vender productos de una
produce } codigo | vende
1..* 1 de 65 aos de edad produce }
1..*
codigo
1
| vende
empresa en la que no
trabaja

Ejemplos(4) Ejemplos(5)
trabajaen trabaja en
Empresa Vendedor Empresa Vendedor
/cantEmp edad
Atributos Calculados /cantEmp edad
Reglas de Negocio
1 1..* (Invariante) 1 1..* (Invariante)
1..* 1..* 1..* 1..*
El atributo cantEmp es la Ningn vendedor menor

Producto
cantidad de empleados de Producto
de 30 aos puede vender
produce } codigo |vende produce } codigo | vende
1..* 1 la empresa 1..* 1 el producto de cdigo X
Contenido
Introduccin
ModelodeCasosdeUso
LaClaseSistema
InteraccionesconelSistema
Anlisis ContratosdeSoftware
Especificacindel
ComportamientodelSistema
Programacin4Curso2013 Anlisis:ComportamientodelSistema 2
Introduccin Introduccin(2)
Duranteestaactividaddeanlisissebusca
describirenformaprecisaculdebeserel Cadaescenariodeloscasosdeusoaanalizares
entendidoentrminosdeunainteraccinentrelos
comportamientoesperadodelsistema actoresinvolucradosyelsistema
SetrabajasobreelModelodeCasosdeUso Aldescribirelsignificadodecadaunodelosmensajes
Viendoalsistemacomounaunidad identificadosencadainteraccinseestespecificandoel
Sedefinenprotocolosquecaractericenelusodelsistema comportamientodelsistema
porpartedelosactoresencadaescenariodeloscasosde
uso
Elcomportamientocompletodelsistemaesespecificadoal
especificarcadamensajedelosprotocolos
Programacin4Curso2013 Anlisis:ComportamientodelSistema 3 Programacin4Curso2013 Anlisis:ComportamientodelSistema 4
Introduccin(3)
Nosenfocamosenquesloquedebehacerelsistema
antecadamensaje
Laformaencmoelsistemaresuelveinternamenteun
mensajeserdefinidadurantelaetapadediseo
ModelodeCasosdeUso ModelodeCasosdeUso(2)
Contenido: Contenido(cont.)
Introduccin Actores
Brevedescripcintextualquesirvecomointroduccinal Todoslosactoresdetectadosparaelsistema
modelo Casosdeuso
Relevamientodefuncionalidades Todosloscasosdeusodefinidos
Descripcintextualdeinformacinnoreflejadaenelrestodel Relaciones
modelo,porejemplo: TodaslasasociacionesentreactoresyCU
Secuenciastpicasenqueloscasosdeusosonutilizadosporlos
Comportamiento
usuarios
Especificacindelcomportamientodecadacasodeusoenel
Otrasfuncionalidadesnocapturadasenloscasosdeuso
modelo,elcualestdefinidopor:EventosdelSistemay
ContratosdeSoftware
LaClaseSistema LaClaseSistema(2)
Duranteestaactividadelsistemaserconsideradocomo
unobjeto: Existeunanicainstanciadeestaclaselacualrepresenta
al sistema entero
QueesinstanciadeunaclaseSistema
Quetieneoperaciones(puederecibirmensajes)
Quetieneunestado
EntodoModelodeCasosdeUsoseasumequeexisteuna Sistema
:Sistema
claseSistema

LaClaseSistema(3) LaClaseSistema(4)
Un actor puede enviar mensajes al sistema invocando
Lasoperacionesdeestaclasepermitenqueelsistema susoperaciones
recibamensajesdelosactores:
Seidentificanaldefinirlosprotocolosquerepresentanlos
escenariosdelosdiferentescasosdeuso
Sistema
Duranteelanlisisnosebuscadisearlas
iniciarVenta
iniciarVenta()
Susemnticaesdefinidaentrminosdelefectoquedeben
agregarProducto()
tenersobreelestadodelsistema terminarVenta()
:Sistema
realizarPago()
LaClaseSistema(5)
Enestaactividadelestadodelsistemaseasume
comounaconfiguracindeobjetosvlida
respectoalModelodeDominio
:Sistema

a1:Artista
c1:Cancin g1:Gnero

c2:Cancin
a2:Artista

g2:Gnero
c3:Cancin

InteraccionesconelSistema InteraccionesconelSistema(2)
Los DSSs se
incluyen en la secc.
Loscasosdeusodescribenlaformaenque Comportamiento
Esc. Tpico del modelo
actoresutilizanalsistemaparacumplirconsus Esc. Alternativo 1
: Cajero
iniciarVenta()
: Sistema
objetivos
CasodeUso1 . * [mas productos]
.
terminarVenta()
total con impuestos
.
realizarPago(monto)
Esnecesarioexpresarestasideasdesdeunpunto
cambio, recibo
Esc. Alternativo n : Cajero

iniciarVenta()
: Sistema
devistatcnico descripcion, subtotal
* [mas productos]
terminarVenta()
total con impuestos
realizarPago(monto)
Modelode
Paraellosedefinenprotocolosquedeterminanla
cambio, recibo
CasosdeUso
Esc. Tpico
interaccinentrelosactoresyelsistema,yasea
: Sistema
: Cajero
iniciarVenta()
Esc. Alternativo 1
* [mas productos]
paraunoovariosescenariosdeuncasodeuso
terminarVenta()
CasodeUso2 .
total con impuestos
realizarPago(monto)
. cambio, recibo
.
CadaprotocoloesexpresadomedianteunDiagramade Un DSS que define
. Esc. Alternativo m : Sistema
: Cajero
SecuenciadelSistema(DSS) la interaccin entre

iniciarVenta()
.
* [mas productos]
los actores y el sistema

.
terminarVenta()
en el escenario dado
total con impuestos
realizarPago(monto)
cambio, recibo
InteraccionesconelSistema InteraccionesconelSistema
EventosdelSistema EventosdelSistema(2)
Uneventodelsistema Ejemplo:
Esunestmuloexterno, ElUsuarioingresaelnombredelacancinyelao
Esgeneradoporunactor Esunestmuloexternogeneradoporunactoranteelcual
Anteelcualelsistemadebereaccionar elsistemadebereaccionar
Esuneventodelsistema
Lasaccionesdelosactores(sobreelsistema)descritasen
ElUsuarioiniciaunasesinenelsistemaoperativo
loscasosdeusosugierenloseventosdelsistema
Esuneventoexternoperonoafectaalsistema
Esnecesarioconsiderarladefinicindeeventodel Noesuneventodelsistema
sistemaparaidentificarlos

OperacionesdelSistema OperacionesdelSistema(2)
Loseventosdelsistemadisparanunaoperacindelsistema Lasoperacionesdelsistemapuedentenerasociados
Estas operaciones son ejecutadas por la instancia sistema parmetros
enresupuestaalaocurrenciadeuneventodelsistema Ejemplo:
Lasoperacionesdelsistemarelativasaunoovarios Elusuarioingresaconeltecladoelcuerpoyelasuntodel
escenariosdeuncasodeusopermitendefinirla email representa un evento que dispara la operacin
interaccinentrelosactoresyelsistema
escribirEmail(cuerpo:String, asunto:String)

Elusuarioseleccionavarioscontactosdeunalista
desplegable representa un evento que dispara la
operacin
elegirContactos(contactos: Set(String))
Diag.deSecuenciadelSistema Diag.deSecuenciadelSistema(2)
EsunartefactoincluidoenelModelodeCasosde
Usoquedefineeilustralainteraccinentrelos UnDiagramadeSecuenciadelSistemapuedeser
actoresyelsistemaenunoovariosescenariosde construidopara:
unCU UnescenariodeunCasodeUso
Incluye: VariosescenariosdeunCasodeUso
Unainstanciarepresentandoacadaparticipante(sistema
yactores) Uncriterioparadecidirentreestasalternativas
Losmensajesenviadosentreellosenel/losescenario/s serlacomplejidaddeestosescenariosyla
correspondiente/s(consusrespuestas) simplicidad(ono)delDSSresultante

Diag.deSecuenciadelSistema(3) Diag.deSecuenciadelSistema(4)
Losdiagramasdesecuenciadelsistemadefinenla Notacin:
conversacinentrelosactoresyelsistema,
enfocndoseenlosmensajesqueelsistema
recibe
Seraposibleincluirademsmensajesenviados
desdeelsistemahacialosactores:
Sinembargoestonoformapartedelconjuntodeservicios
queelsistemabrinda(ycuyaespecificacineselobjetivo
delapresenteactividad)
Nombre del Diagrama Sistema

Diag.deSecuenciadelSistema(5)
Tipodeunatributo(otipoderetorno)cuandonoes Actor
simple,sinoqueesunacoleccindeciertodatatype
Tipo
Iteracin
Criterio de
ingresarNombre(nombre:String):DataCancion parada

Alternativo
PuedeutilizarseSet(Tipo),sisequierepasarcomo
parmetro(oretorno)varioselementosdeunsolotipo Operacin
(porejemplo:unalistadeelementos) del sistema
listarCanciones():Set(DataCancion)
Respuesta
TIEMPO
del sistema
DefinicindeunDSS: Lmitedelsistema:
1. Incluirunainstanciaquerepresentealsistema Paraidentificareventosdelsistemaestilpensarenel
comounaunidad lmitedelsistema
2. Identificarcadaactorqueparticipeenel/los Ellmitesueledeterminarseparaquecoincidaconel
escenario/sconsiderado/seincluirunainstanciapara sistemadesoftware(yeldehardwaretambin)
cadauno Buscaraquelloqueocurrafueradeeselmiteyqueadems
3. Deladescripcindelcasodeusoidentificaraquellos loatraviese
eventosquelosactoresgenerenysean
deintersparaelsistemaeincluircadaunode
elloscomounmensaje
Lmitedelsistema(cont.): Lmitedelsistema(cont.):
Esresponsabilidaddelsistemareaccionaranteelevento Lasoperacionesdelsistemadeberanretornar
X? exclusivamentedatatypesotiposprimitivos
EsXexterno? Se est comprando
un producto promocional
(ver que hacer con eso):
es interno al sistema
Lmite del Sistema
El Cliente elige
un producto: no es SISTEMA El Cajero ingresa
de inters para el sistema
cdigo del producto
(elegido por el Cliente):
eso s es de inters

MemoriadelSistema: MemoriadelSistema(cont.):
Elsistemapuede(ono)tenermemoria: Paraindicarlamemoriadeunsistema,generalmente
Sinmemoria,losmensajessonindependientes bastaconindicarloenelnombredeldiagramay
Con memoria, cada mensaje puede recordar mediantelautilizacindenotaseneldiagrama
lainformacinutilizadaenunestadopreviodelsistema Alternativamente,puedeutilizarseundiagramade
Debeindicarseclaramentesielsistematieneono estructuraestticaenaquelloscasosenqueinterese
memoria,yencasodetenerla,quinformacinrecuerda indicarunaestructuracomplejadedichamemoria
Ejemplo:DSSsinmemoria Ejemplo:DSSconmemoria
el sistema
recuerda la CI

ErroresComunes
QuSigue?
Envodemensajeshaciaelusuario Unavezidentificadaslasoperacionesdelsistemaesposible
especificarsucomportamiento
Desconocerlamemoriadelsistema
Noespecificardatatypes utilizados Estaespecificacinexpresaelefectoqueunaoperacin
tendrsobreelsistema
Sobrecargardeinformacinundiagramade
secuenciapudiendorealizarvariosdeellos ParaelloserealizarunContratodeSoftwareparacada
Noindicartipodeparmetrosnivalorderetornode operacindelsistema
losmensajes
QuSigue?(2) Los contratos se

incluyen en la secc.
Comportamiento
del modelo
Contrato:
iniciarVenta()
Contrato:
agregarProducto()
Modelode
CasosdeUso
Contrato:
cancelarVenta()
Contrato:
confirmarVenta()
ContratosdeSoftware
ContratosdeSoftware EnfoquedeContratos(1)
Uncontratodesoftwareespecificael
Obligaciones Derechos
comportamientooefectodeunaoperacin
Laespecificacinesdeclarativaynoimperativa Consumidor Satisfacer Obtener la
EstatcnicaestbasadaenlasternasdeHoareen precondiciones postcondicin
satisfecha
lasque:
Sedescribenpropiedadesdelresultado,enlugardedarun Proveedor Satisfacer Procesamiento
conjuntodepasosoinstruccionesqueindiquencmo postcondiciones asumiendo
calcularlo como satisfecha
la precondicin
ContratosdeSoftware ContratosdeSoftware
EnfoquedeContratos(2) EnfoquedeContratos(3)
ElConsumidorsecomprometeasatisfacerla
precondicinalinvocarlaoperacin: ElProveedorsecomprometeasatisfacerlapostcondicin
Silasatisface:tienederechoaexigirquelapostcondicin alfinalizarlaoperacinsolamentecuandolaprecondicin
sesatisfaga fuesatisfechaalmomentodelainvocacin
Sinolasatisface:noselegarantizalacorrectituddel Elcompromisonocomprendeelcasoenquela
resultadodelainvocacin(selanzanexcepciones) precondicinnofuesatisfecha:
PorestaraznesresponsabilidaddelConsumidor EnesecasoelProveedorpuededevolverunvalorarbitrario
yelConsumidortienequeaceptarloysaberquhacercon
sabercundoinvocaralaoperacin(ymanejaren l
formaadecuadaelresultado)

EnfoquedeContratos(4) EnfoquedeContratos(5)
Consumidor: Precondicin:
Prefiereprecondicionesdbiles:implicamenostrabajo EsaloquedebeaccederelConsumidorparaobtenerel
Prefierepostcondicionesfuertes:implicamsresultados resultadodeseado
Proveedor: EsloquedebeexigirelProveedorparallegaralresultado
Prefiereprecondicionesfuertes:implicamenos Postcondicin:
preocupaciones EsaloqueaccederelConsumidor
Prefierepostcondicionesdbiles:implicamenostrabajo EsaloquesecomprometeelProveedor
EnfoquedeContratos(6) ContratosdeOperaciones
TantolasPrecomolasPostlasdeterminaelProveedor Loscontratossepuedenrealizarparaoperacionesde
ElConsumidor: cualquiertipodeclase
ViendolaPostsabequvaaobtener(sinsabercmo) Enestaactividadlasrealizaremosparaoperaciones
ViendolaPresabeacambiodequobtieneelresultado delsistema
ParaunaoperacinXtendremos{P}S{Q}
PeslaprecondicindeX(especificada)
SeselprogramaqueimplementaX(aserdiseadoms
adelanteenlaetapadeDiseo)
QeslapostcondicindeX(especificada)

ContratosdeSoftware
ContratosdeOperaciones(2) ContratosdeSoftware
Condiciones
Quinutilizaelcontrato(partesPyQ)deuna Enqutrminosseexpresanlasprey
operacin? postcondiciones?
UndiseadordenuestroequipoquedebadisearS Yparaelcasoparticulardeoperacionesdel
Parasaberquesloquetienequelograrsudiseodelaoperacin
sistema?
Enfuncindeloanteriorparadecidircmosereldiseodelaoperacin
(parteS) Entrminosgeneralesestascondicionesrefieren
Undesarrolladordeotroequipoquedebainvocarlaoperacin alestadodelsistemaantesydespusdela
(eldiseooimplementacindeSnoessuresponsabilidad) invocacinalaoperacin
Parasaberquesloquelaoperacinhacesintenerquevereldiseoola
implementacindeS Lasprecondicionesrefierenademsalosargumentos
delaoperacin
Laspostcondicionesrefierenademsalvalorretornado
porlaoperacin(siexiste)
Condiciones(2) Condiciones(3)
LasPrecondicionesrefierenalmomentoprevioala LasPostcondicionesrefierenalmomento
invocacinyexpresan posterioralainvocacinexpresancondiciones
condicionessobre sobre
Losvaloresdelosparmetrosdelaoperacin Elvalorderetorno(sicorresponde)
Elestadodelsistema: Elestadodelsistema:
Lacreacindeobjetos Lacreacindeobjetos
Ladestruccindeobjetos Ladestruccindeobjetos
Laconexindeobjetos Laconexindeobjetos
Ladesconexindeobjetos Ladesconexindeobjetos
Lamodificacindelvalordeatributosdeobjetos Lamodificacindelvalordeatributosdeobjetos

Creacindeobjetos: Conexindeobjetos:
Pre:Declararqueelobjetonoexiste Pre:Declararquelosobjetosnoestnconectados
Post:Declararqueelobjetoexiste Post:Declararquelosobjetosestnconectados
Destruccindeobjetos: Desconexindeobjetos:
Pre:Declararquelosobjetosestnconectados
Pre:Declararqueelobjetoexiste
Post:Declararquelosobjetosnoestnconectados
Post:Declararqueelobjetonoexisteyquetodoslos
objetosqueestabanconectadosalyanoloestn Modificacindelvalordeatributosdeobjetos:
Pre:Declararqueelobjetoexista
Post:Declararqueelatributodelobjetotieneelvalordado
Ejemploparaoperacin
crearCancion(nombreCancion:string, nombreArtista:string) 1 a:Artista a:Artista
Precondicin:NoexisteunobjetoCancindenombre nombre = Bruno Mars
nombreCancionenelsistema 2 nombre = Bruno Mars
Precondicin:ExisteunobjetoArtistaadenombre
nombreArtista
Postcondicin:SecreaunanuevainstanciadeCancionc
denombrenombreCancionyconatributoid c:Cancin
autogeneradotalqueelidseanicoenelsistema. nombre=TheLazySong
Postcondicin:Hayunlinkentrecya id=15

Sepuedederivarquelaoperacincreaalobjetodetipo Se pasa del estado 1 al estado 2 mediante la ejecucin de
CancinyloconectaconelobjetoArtista
crearCancion(The Lazy SOng, Bruno Mars);
Condiciones(8) EstructuradeContratos
Expresacondicionessobreelestadoinicialysobreel Uncontratoesunartefactotextualqueseincluye
estadofinalqueindicanquesloquelaoperacin en la seccin Comportamiento del Modelo de
hace,peronocmolohace CasosdeUso
NOdicecmodebeimplementarselaoperacindel Estestructuradodelasiguienteforma:
sistemacrearCancion()
Firma:Cabezalsintcticodelaoperacin
Parmetros:Descripcindelosparmetrosdelaoperacin
Responsabilidades:Descripcindelasresponsabilidades,
unaideadeloquedeberealizarlaoperacin
EstructuradeContratos(2) EstructuradeContratos(3)
Estructura(cont.) Estructura(cont.)
Referenciascruzadas:Caso(s)deUsoalosquepertenecela Postcondicin:Descripcindelestadodelainstanciadel
operacin sistemaalaqueseleapliclaoperacin
Snapshots:(Opcional)
Salida:Resultadodelaoperacin(slosiesunafuncin)
Paresdesnapshotsqueejemplifiquenelestadodelainstanciaa
Precondicin:Descripcindelestadodelainstanciadel laqueseleapliclainvocacin,previoyposterioralainvocacin
sistemaalaqueseleaplicarlaoperacin,yotras Lainvocacinconcretaqueproduceelcambioejemplificado
condicionesqueseanecesarioasumirprevioalaaplicacin (mostrandolosparmetrosefectivos)
(porejemplo,conrespectoalosparmetros)

ContratosdeSoftware
ErroresComunes QuSigue?
Incluirinvariantescomopostcondiciones Hastaelmomentosetienenidentificadasy
Omitirelresultadodeunaoperacincomo
especificadaslasoperacionesdelsistemapara
postcondicin todosloscasosdeusodefinidos
Esposibleahorarealizarundiseoenelque
Seidentifiquenlosobjetosquerealmenteparticiparnenla
solucin
Sedefinaninteraccionesentredichosobjetostalquecada
unacumplauncontratocorrespondienteaunaoperacin
delsistema
Contenido
Objetivo
Introduccin
ImplementarelModelodeDominio
GeneracinParcialdeCdigo ImplementarelDSS
Conclusiones
Programacin4Curso2013 GeneracinParcialdeCdigo 2
Objetivo Introduccin(1)
Elobjetivodeestetemaesilustrarunposibleusoquese LaetapadeAnlisisproducelossiguientesartefactos:
lepuededaralosartefactosconstruidosenlaetapade ModelodeDominio
Anlisis. DiagramadeSecuenciadelSistema
Sedebetenerespecialcuidadoenrecordarqueel Severaqucmogenerarcdigoapartirdeestosdos
procesodedesarrolloannohafinalizadoyque artefactosylasconsecuenciasqueestoconlleva.
normalmentesedebeatravesarlaetapadeDiseoantes
deimplementar.
Programacin4Curso2013 GeneracinParcialdeCdigo 3 Programacin4Curso2013 GeneracinParcialdeCdigo 4
Introduccin(2) Imp.elModelodeDominio(1)
Severcomo,primero,generarunesqueletodelcdigo Dadoque
delasclasesapartirdelaestructuracontenidaenel UnModelodeDominiopresentalosconceptosms
ModelodeDominio(Implementar el Modelo de relevantesdelproblema,yque
Dominio)yluegocomogenerarunesqueletodel LaPOO permite reducir la brecha entre elproblemayla
mtodomain()apartirdelcomportamientocontenido solucin(brindandoconstruccionesqueaplicanenambos
enelDiagramadeSecuenciadelSistema(Implementar contextos).
elDSS).
entonces parecelgicoconcluirquelosconceptos
puedenserconsideradoscomoclasescandidatas.

Imp.elModelodeDominio(2) Imp.elDSS(1)
Esposiblegenerarunesqueletodecdigo, LosDiagramasdeSecuenciadelSistemailustrancmolos
particularmentedesuestructura(nodesu usuariosinteractanconelSistema(comocajanegra).
comportamiento)asumiendoquelosconceptos MuestranquoperacionesserninvocadasalSistemay
identificadosenelAnlisissernclasesadecuadasenel enquorden,ascomoparmetrosyretornodecada
Diseo. una.
Anasfaltarnelementos(ademsdelosmtodos) Estoesimportantealmomentodedesarrollarlainterfaz
comolosTiposAsociativos. grficadeusuario(GUI)queharinvocacionesa
Portantoesteesqueletodecdigodebeconsiderarse operacionesdela clase Sistema sugerida enlosDSS.
comomodificableynofinal.
Imp.elDSS(2) Imp.elDSS(3)
Porlotantosepuede(intentar)generarunesqueletodel Anastambinfaltarnelementos,siendoelms
cdigodelmtodomain()apartirdelainformacin notablequesenosesabequinimplementalas
contenidaenlosDSS. operacionesdelSistema,yporelloseasumelaexistencia
Sedeberasumirquetodasesasoperacionessern delaclaseSistemaquelasproveeatodas.
provistasporunanicaclase(laclaseSistema)puessa Luego,elDiseoespecificarcmoseorganizarnlas
eslavisindecajanegradelosDSSenlaetapade operacionesdelSistema.
Anlisis. Portantoesteesqueletodecdigodebeconsiderarse
comomodificableynofinal.

Conclusiones(1) Conclusiones(2)
SepuedenutilizarlosartefactosdeAnlisisparala Noobstanteresultainteresanteverdesdetempranola
generacin(parcial)decdigo. utilidadyelpotencialdelosartefactosdeAnlisis.
Debequedarclaroquesibienesposiblegenerarcdigoa Asimismo,cabemencionarqueotrasmetodologasde
partirdestos(realizandociertashiptesis)noesposible desarrollodesoftwarehacenusodeideassimilaresa
generartodoelcomportamientoconcretodetodaslas estasparaacortarlostiemposdedesarrollo,tpicamente
operaciones. acortandoelDiseo.
EnlaetapadeDiseosedefineelcomportamientode
dichasoperacioens
OperacinyMtodo
Operacin:especificacindeunatransformacino
consultaqueunobjetopuedeserllamadoaejecutar
Mtodo:implementacindeunaoperacinparauna
determinadaclase
ConceptosBsicosdeOrientacina
Objetos(2daparte)
Programacin4Curso2013 ConceptosBsicosdeOrientacinaObj(2daparte) 2
OperacinyMtodo PolimorfismoyRedefinicin
Eslacapacidaddeasociardiferentesmtodosa
class Usuario {
lamismaoperacin
private:
int idUsuario; Cuandoenunajerarquadegeneralizacinse
DateTime* nacimiento; encuentramsdeunmtodoasociadoala
mismaoperacin,sedicequedichaoperacin
public: estredefinida
int getEdad()
{
... // un cierto algoritmo
}
}; Mtodo para getEdad() en Usuario
Programacin4Curso2013 ConceptosBsicosdeOrientacinaObj(2daparte) 3 Programacin4Curso2013 ConceptosBsicosdeOrientacinaObj(2daparte) 4
RedefinicindeOperaciones
Class Usuario {
private:
int permisos; // set de bits
Interfaz
public: Una interfaz esunconjuntodeoperacionesalquesele
};
virtual int getPermisos(); aplicaunnombre
int Usuario::getPermisos(){
Nodefineunestadoparalasinstanciasdeestos
return permisos; elementos,nitampocoasociaunmtodoasus
}
operaciones
class Admin: public Usuario {
public: Esteconjuntodeoperacionescaracterizael(opartedel)
static int ADMIN_SISTEMA;
public:
comportamientodeinstanciasdeclases
int getPermisos();
};
int Admin::getPermisos(){
int p = Usuario::getPermisos();
return (p | ADMIN_SISTEMA);
}

Interfaz(2) Interfaz(3)
// Una interfaz para implementar lecturas secuenciales sobre algo
Unaclaserealizaunainterfazenformaanloga class Archivo {
acmountipoimplementaunTAD public:
// lee hasta n caracteres y avanza
CuandounaclaseCrealizaunainterfazI, // la ltima posicin leda y devuelve
// su contenido en el string
puededecirsequeunainstanciadeC: virtual string read(int n) = 0;
Es de C o es un C pero tambienque, // pone la ltima posicin leda al
// principio del archivo
Es de I o es un I virtual void rewind() = 0;
// dice en qu posicin se va a leer
Estopermitequebrarlasdependenciashacia virtual int position() = 0
// dice cuntos caracteres hay disponibles
las implementaciones cambindolas por una virtual int available() = 0
sola dependencia hacia la especificacin (la
virtual ~Archivo() {};
interfaz) };
CualquierclasederivadadeArchivoserunArchivo.
Realizacin Realizacin(2)
class CPPArchivo: public Archivo {
private:
Esunarelacinentreunaespecificacinysu fstream f;
implementacin public:
CPPArchivo(const string& ruta);
Unaformaposiblederealizacinseproduceentre
// implementacin de interfaz Archivo
unainterfazyunaclase string read(int n);
void rewind();
SedicequeunaclaseCrealizaunainterfazIsiC int position();
implementatodaslasoperacionesdeclaradasenI,es int available();
decirproveeunmtodoparacadauna // operaciones extra
void close();
void write(const string& s);
void setPosition();
~CPPArchivo();
};
Realizacin(3) Realizacin(4)
CPPArchivo::CPPArchivo(const string& ruta):
f(ruta)
{} Unainterfazpuedeserentendidacomola
// ...
string CPPArchivo::read(int n){
especificacindeunrolquealgnobjetodebe
char *buffer = new char[n]; desempearenunsistema
f.read(buffer, n);
string res = string(buffer, n); Unobjetopuededesempearmsdeunrol:
delete buffer;
return res; Unaclasepuederealizarcualquiercantidadde
} interfaces
// ...
int CPPArchivo::position(){ Unrolpuedeserdesempeadoporobjetosde
}
return f.tellg(); caractersticasdiferentes:
// ... Unainterfazpuedeserrealizadaporcualquier
CPPArchivo::~CPPArchivo(){
f.close();
cantidaddeclases
}
class Comparable {
Esposibletiparaunobjeto(ademsdecomoes public:
usualmediantelaclasedelacualesinstancia) // devuelve algo mayor a 0 si this > b
// 0 si this = b, o algo negativo si this < b
tambinmedianteunadelasinterfacesquesu virtual int comparar(Comparable *b) = 0;
claserealiza virtual ~Comparable() {};
};
Porloquesiunobjetoesdeclaradocomodetipo
I(enunalistadeparmetros,comoatributo, class Representable {
public:
etc.),siendoIunainterfaz,significaqueese // devuelve una representacin del objeto
objetonoesunainstanciadeI(locualnotiene virtual string toString();
sentido)sinoqueesinstanciadeunaclaseque virtual ~Representable() {};
}
realizalainterfazI

class Integer: public Comparable, public Representable { Estemecanismopermiteabstraersedela
private: implementacinconcretadelobjetodeclarado
int val;
public: Enlugardeexigirquedichoobjetopresenteuna
Integer(int val);
int getVal(); implementacindeterminada(esdecir,quesea
string toString(); instanciadeunadeterminadaclase),seexigeque
int comparar(Comparable *c);
}; presenteundeterminadocomportamientoparcial(las
ostream& operator <<(ostream& o, Representable& r) operacionesdeclaradasenI)
{
return o << r.toString();
Estecomportamientoesimplementadoporunaclase
} querealicelainterfaz,ydelacualelobjetoen
void Utilidades::ordenar(Comparable **arr, int largo) cuestinesefectivamenteinstancia
{
// ;)
}
Realizacin(8) Dependencia
Notarqueenladefinicinpreviaseasumequela Esunarelacinasimtricaentreunpardeelementos
clasequerealizalainterfazesconcreta dondeelelementoindependientesedenominadestinoy
Esposiblesinembargoqueunainterfazsea eldependientesedenominaorigen
realizadaporunaclaseabstracta Enunadependencia,uncambioenelelementodestino
Encuyocasodebedeclarartodaslasoperacionesde puedeafectaralelementoorigen
lainterfazaunquenoestaobligadaa Lasasociaciones,generalizacionesyrealizacionescaen
implementarlasatodas
dentrodeestadefinicingeneral
SiCesabstractayrealizalainterfazI,entoncesun
objetodeclaradocomodetipoIdebeserinstancia Perosonunaformamsfuertededependencia
dealgunasubclaseconcretadeC(odeotraclase Enesoscasosladependenciaseconsideraasumiday
querealicelainterfazI) noseexpresaexplcitamente(porejemploen
DiagramasdeClasesdeDiseo)

Contenido
Introduccin
Programacin 4
Objetivos
Arquitectura Lgica
Diseo Diseo de Bajo Nivel
Programacin 4 | Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2
Introduccin Introduccin (2)

Durante el anlisis un caso de uso fue La Arquitectura de Software busca expresar la
reformulado en trminos de estructura global de una aplicacin
interacciones entre los actores y el El nivel de abstraccin empleado para expresar
dicha estructura es mayor que el empleado para
sistema (DSS)
detallar la solucin al problema de software
El efecto de cada mensaje fue planteado
especificado en forma precisa (Contrato) El objetivo de la arquitectura no es detallar la
Es el momento de definir cmo hace el solucin adoptada sino que es proveer una
sistema internamente para resolver cada visin global de la misma para simplificar su
comprensin
una de las operaciones del sistema
Programacin 4 | Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 3 Programacin 4 | Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 4
Introduccin (3) Objetivos
Uno de los puntos de vista desde donde
se suele estudiar la estructura de una Definir la estructura interna del sistema a
aplicacin es la estructura interna construir
La arquitectura desde ese punto de vista Realizar el diseo de las operaciones del
se denomina Arquitectura Lgica sistema
A definir cmo se resuelven las
operaciones del sistema en esta
estructura se le llama diseo de bajo
nivel (o simplemente diseo)
Arquitectura Lgica Arquitectura Lgica (2)

La arquitectura lgica se define como un Existen guas de particionamiento
conjunto de componentes lgicos Cada una de ellas propone
relacionados entre s, con Un tipo de particin particular
responsabilidades especficas Asignacin de responsabilidades a los
Estos componentes se obtienen a partir la componentes resultantes
sucesiva particin del sistema en Se denominan estilos o patrones de
componentes con responsabilidades ms arquitectura
concretas (enfoque top-down) La eleccin del estilo a aplicar depende del
tipo de sistema que se est construyendo
Aspectos de una Aplicacin Aspectos de una Aplicacin (2)
El diseo de un sistema de software
comprende la resolucin de mltiples aspectos Disear e implementar en forma conjunta
de una aplicacin diferentes aspectos
La forma en que esos aspectos sean resueltos Usualmente simplifica la arquitectura, pero
determina la flexibilidad del diseo
Complica el diseo
Desde un punto de vista lgico es preferible
separar el diseo de aspectos diferentes para La separacin de aspectos generalmente
Permitir que evolucionen independientemente Complica la arquitectura (estructura general)
Simplificar el problema y tener mejor visibilidad Simplifica el diseo de cada uno al permitir
de las partes que componen la aplicacin enfocarse en cada aspecto por separado
Aspectos de una Aplicacin (3) Aspectos de una Aplicacin (4)

class Persona { Aspectos de presentacin En el ejemplo anterior se detectan
//atributos
fragmentos de cdigo con diferentes
void mostrar() { Aspectos de lgica propsitos en una misma clase
write(atributos); de la aplicacin
} Cdigo para procesar la informacin existente
que implementa la lgica de la aplicacin,
void procesar(entrada) {
//hacer algo con entrada y atributos Cdigo de interaccin con el usuario, y
}
Cdigo que sirve para almacenar los datos en
void guardar() {
Aspectos de acceso un medio persistente
write(arch,atributos);
a la persistencia de
} datos
}
Aspectos de una Aplicacin (5) Aspectos de una Aplicacin (6)
Esto es comn a la mayora de los sistemas Incluir los tres aspectos en una misma
de informacin interactivos clase no resulta flexible
Se puede decir que estas aplicaciones La clase completa queda dependiente de
abarcan bsicamente tres aspectos La forma en que los datos son mostrados u
Presentacin: incluye todo lo referente a la interaccin obtenidos del usuario, y adems de
del sistema con los usuarios en el mundo exterior La forma en que los datos son almacenados
Lgica: se encarga del procesamiento particular que Es deseable establecer una separacin
el sistema deba realizar sobre la informacin que
de dichos aspectos
maneja
Persistencia: consiste en el almacenamiento Es decir, mantener el cdigo referente a
persistente de dicha informacin cada aspecto en clases separadas
Aspectos de una Aplicacin (7) Arquitectura en Capas

Esto sugiere un criterio concreto de Una Arquitectura en Capas es la
particin de componentes arquitectura de un sistema que haya sido
particionado segn el estilo de Capas
Presentacin
Define diferentes niveles de elementos
Lgica
Los elementos de un mismo nivel tienen
responsabilidades de abstraccin similar
Los elementos de un nivel estn para
Persistencia
atender los pedidos de los elementos del
nivel superior
Arquitectura en Capas (2) Arquitectura en Capas (3)
3
La particin definida anteriormente es
compatible con el estilo de Capas
2 Se definen por lo tanto las siguientes capas
Pedido
Presentacin
1 Lgica
Persistencia
Respuesta
Los actores utilizan solamente la capa de
presentacin
La capa de persistencia no requiere de los
servicios de ninguna otra

Qu hay en cada capa?
Presentacin
Presentacin: clases que se encargan de capturar
Interfaz del sistema la entrada de los usuarios y mostrar informacin
(contiene operaciones
del sistema) Lgica:
Clases que describen los objetos que procesarn la
Lgica informacin para satisfacer los casos de uso del
sistema
Clases que permiten a las anteriores acceder a los
datos
Persistencia Persistencia: datos del sistema que necesiten ser
preservados (texto plano, base de datos, etc.)
Usualmente la capa lgica es refinada de la Ejemplo Lgica
siguiente manera Serv. Sistema
ISistema IRetiro Cajero

Lgica
Present. ingresarTarjeta()
ingresarPIN()
21/4/2005;
Es este elemento seleccionarCuenta()
1001-345-7612;
Menu
Servicios el que realiza la(s) $U 1200,00
del Sistema interfaz(ces) del mostrarMenu()
Transaccion
sistema
Acceso
a Datos Acceso
a Datos
Operaciones del Sistema Operaciones del Sistema (2)

Evento del Sistema
Los Diagramas de Secuencia del
Sistema ilustran la forma en que los : Cliente
: Sistema Presentacin
ingresarPIN()
actores realizan invocaciones sobre el ingresarTarjeta()
Menu
sistema mostrarMenu()
: Cliente
ingresarPIN()
Al estudiar la Arquitectura Lgica es ingresarPIN()
seleccionarCuenta()
posible profundizar en los detalles de Serv. Sistema
.
cmo se realizan dichas invocaciones .
Cajero
Operacin del
. ingresarTarjeta() sistema
ingresarPIN()
seleccionarCuenta()

Implementacin Implementacin (2)
// pertenece en forma lgica a la Capa de Presentacin // pertenecen en forma lgica a la Capa Lgica
class Menu { interface IRetiro {
IRetiro atm; void ingresarTarjeta();
void ingresarPIN();
void mostrarMenu() { void seleccionarCuenta();
// leer en t el nmero de tarjeta }
atm.ingresarTarjeta(t);
// leer en p el nmero de PIN class Cajero realize IRetiro {
atm.ingresarPIN(p); public void ingresarTarjeta() {...}
// leer en c el nmero de cuenta public void ingresarPIN {...}
atm.seleccionarCuenta(c); public void seleccionarTarjeta() {...}
. .
. .
} }
Diseo de Bajo Nivel Objetivos
Tenemos definida la estructura interna del Disear Colaboraciones que realicen los Casos
de Uso del sistema
sistema a construir (Arquitectura Lgica)
Se busca disear una colaboracin por cada caso de
A partir de dicha estructura definimos uso (o varios de ellos juntos)
cmo se resuelven internamente cada Una colaboracin realiza un conjunto de casos de uso
cuando define su solucin
una de las operaciones del sistema
Esta relacin es la misma que se puede definir entre
En este curso, el diseo de bajo nivel una interfaz y un conjunto de clases
estar enfocado en la capa lgica Relacin de Realizacin
Caso de Uso Colaboracin

Colaboracin Colaboracin (2)
Una Colaboracin est compuesta por La estructura de la colaboracin indica

Una Estructura: que indica quin participa y sus propiedades
Las clases de objetos que participan en la Las interacciones de la colaboracin
solucin de los casos de uso
indican cmo los participantes logran el
Los atributos de las mismas y sus relaciones
Las operaciones que pueden ser invocadas
resultado
sobre sus instancias Las colaboraciones aparecen
Interacciones: que definen la forma en que especificadas en el Modelo de Diseo
objetos de las clases dadas se comunican
para obtener el resultado deseado
Colaboracin (3) Enfoque

Por lo tanto una Colaboracin que realice Existen dos enfoques para disear una
colaboracin
un conjunto de Casos de Uso contendr
Definir primero la estructura y luego generar
La estructura de los participantes las diferentes interacciones respetndola
Una interaccin en trminos de dichos Definir libremente las interacciones y luego
participantes para cada operacin del sistema definir la estructura necesaria para que stas
En cada interaccin se detalla la forma en que la puedan ocurrir
operacin del sistema es resuelta En el curso seguiremos el segundo
enfoque

Actividades Diseo de Interacciones
Para lograr los objetivos planteados Consiste en definir comunicaciones entre
objetos que permitan resolver operaciones del
realizaremos las siguientes actividades
sistema
Diseo de interacciones
Esta definicin se realiza libremente
Diseo de la estructura Los protagonistas aparecen sugeridos en el
Modelo de Dominio
El resultado es el especificado en el contrato de la
operacin del sistema a disear
La libertad est dada en los mensajes que los
protagonistas se puedan enviar entre s
Herramienta: Diagrama de Comunicacin
Diseo de la Estructura Consideraciones

Consiste en especificar completamente la
Durante la etapa de diseo de una metodologa
estructura necesaria para que todas las iterativa e incremental se obtienen un conjunto
interacciones puedan ocurrir de colaboraciones que comprenden todos los
Se busca especificar la estructura de una casos de uso del sistema
colaboracin En consecuencia, se obtiene un diagrama de
Por lo tanto es necesario considerar todas comunicacin por operacin del sistema y un
las interacciones del caso de uso que la conjunto de DCDs, uno por colaboracin
colaboracin realiza Los DCD pueden requerir algn tipo de revisin
Recordar que se define una interaccin por general de alguien con una visin global de la
cada operacin del sistema solucin a los efectos de eliminar inconsistencias
Herramienta: Diagrama de Clases de Diseo
Consideraciones (2) Consideraciones (3)
Durante el diseo la idea clave es la de A pesar de que pueden existir varias
asignacin de responsabilidades soluciones no todas tienen buenas cualidades
(flexibilidad, extensibilidad, adaptabilidad, etc.)
La asignacin de responsabilidades se Buscaremos encontrar soluciones que
realiza (en parte) definiendo operaciones adems presenten buenas cualidades
para los participantes de la solucin Para ello utilizaremos criterios de asignacin
Es posible definir diferentes interacciones de responsabilidades
para lograr un mismo efecto Estos criterios buscan evitar la toma de malas
decisiones al momento de asignar
Esto es asignando responsabilidades en
responsabilidades
maneras diferentes
Modelo de Diseo Modelo de Diseo (2)

El Modelo de Diseo es una abstraccin El Modelo de Diseo tambin incluye las
de la solucin lgica al problema interacciones que realizan los casos de
Incluye todas las clases de objetos (y uso
otros elementos) que conforman la Una interaccin est expresada en
estructura necesaria para el trminos de elementos de diseo del
funcionamiento del sistema modelo
Dichos elementos pueden estar
eventualmente organizados en paquetes
de diseo
Modelo de Diseo (3) Modelo de Diseo (4)
Contenido Contenido (cont.)
Introduccin: Breve descripcin que sirve Relaciones: Las relaciones del modelo
como introduccin al modelo entre clases e interfaces
Clases: Las clases del modelo Colaboraciones: Las realizaciones de
Interfaces: Las interfaces del casos de uso del modelo
modelo Diagramas: Representacin de los
elementos del modelo
Resumen : Cajero
iniciarVenta()
: Sistema
Cont. 1
Object1
Message1
Message2
Object2
agregarProducto(id,cant) Object3
* [mas productos] Message1

terminarVenta()
Cont. 2
Object1 Object2
total con impuestos
Programacin 4
Object3
cambio, recibo
Esc. Tpico
: Sistema
: Cajero
Esc. Alternat. 1
iniciarVenta()
Cont. 1
Caso de Uso .
.
* [mas productos]
terminarVenta()
Message1
.
total con impuestos
Cont. 3
realizarPago(monto) Object1 Object2
cambio, recibo
Esc. Alternat. n
Message2
Object3
: Sistema
: Cajero
iniciarVenta()
Diseo
Cont. 1
* Association1 * Class4
Class1 descripcion, subtotal
-atr3
-atr1 * [mas productos]
-atr4 terminarVenta()
total con impuestos

*
* Association2
Cont. 4
Class2 Class3 cambio, recibo
Object1 Object2
-atr2
Diagramas de Comunicacin
Message2
Object3
Class4
Class1 * Association1 * -atr3
-atr1 -atr4
+operacion1()
+oper1()
+operacion2()
+oper5()
*
Class2 Class3 * Association2
-atr2
Colaboracin +oper2()
+oper3()
+oper4()
Programacin 4 | Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 43

Contenido Diagramas de Interaccin
Diagramas de Interaccin UML incluye los diagramas de interaccin
Notacin que sirven para mostrar ejemplos de cmo
Reuso de Elementos de Diseo ciertos objetos interactan a travs de
mensajes para la realizacin de tareas
Existen varios tipos de diagramas de
interaccin que son semnticamente
equivalentes entre s, en particular:
Diagramas de Secuencia
Programacin 4 | Diseo: Diagramas de Comunicacin www.fing.edu.uy/inco/prog4 | 2010 | 2 Programacin 4 | Diseo: Diagramas de Comunicacin www.fing.edu.uy/inco/prog4 | 2010 | 3
Notacin
Diagramas de Interaccin (2) Instancias
Un Diagrama de Secuencia Las instancias se representan igual que en
: ClaseA : ClaseB los diagramas de instancias
mens1()
mens2()
Corresponden a una instancia cualquiera
de una cierta clase o interfaz (no a una
mens3()
instancia real)
Su Diagrama de Comunicacin equivalente : Persona p : Persona p / Rol : Persona
1: mens2() Sin nombre Con nombre Cuando existen

varias formas de
mens1() 2: mens3()
acceder a esa
: ClaseA : ClaseB
instancia
Notacin Notacin
Clases Links
Las clases se representan con el nombre Representa una conexin entre instancias
de la clase dentro de un rectngulo que indica navegabilidad y visibilidad entre
Corresponden a una clase no a una ellas
instancia Establece una relacin de cliente/servidor
entre las instancias
Persona
Clase Persona : Empresa : Persona
Notacin Notacin
Mensajes Parmetros
Los mensajes son representados mediante Los parmetros se muestran entre
una flecha etiquetada parntesis a la derecha del nombre del
Un mensaje est asociado a un link y tiene mensaje
asignado un nmero de secuencia que Se puede mostrar adems su tipo
determina el orden de ocurrencia
1: aumentarSueldo(s:Real)
1: contratar()
: Empresa : Persona
2: asignarSeccion()
3: asignarCliente()
: Empresa : Persona
Notacin Notacin
Tipo de Retorno Sintaxis de Mensajes
El valor de retorno puede ser mostrado a la La sintaxis de los mensajes es la siguiente:
izquierda del mensaje, con un := en medio [ret :=] mensaje([param [: TipoParam]]) [: TipoRet]
Se puede mostrar adems el tipo del valor Donde:
de retorno ret almacena el resultado de la operacin (opcional)
mensaje es el nombre del mensaje enviado (y de la
1: s := obtenerSueldo() : Real
operacin invocada)
: Empresa : Persona param son argumentos usados en el envo
TipoParam es el tipo de cada parmetro (opcional)
TipoRet es el tipo del recorrido de la operacin
(opcional)
Notacin Notacin
Iteracin Creacin de Instancias
Las iteraciones se indican mediante un La forma de ilustrar la creacin de una
asterisco (*) a continuacin del numero de instancia es enviando el mensaje create
secuencia del mensaje Este mensaje puede incluir parmetros
Esto expresa que el mensaje es enviado en
Lo usual es especificar un nombre para la
forma repetida (en un loop) al receptor
class Simulador {
instancia para poder utilizarla despus
Generador gen;
1* [i:=1..n] : x := generar()
1: e := create()
: Simulador : Generador void unaOper() {
for (i from 1 to n) { : Empresa : Empleado
x = gen.generar();
}
}
Notacin Notacin
Destruccin de Instancias Nmeros de Secuencia
La forma de ilustrar explcitamente la El orden de ocurrencia de los mensajes
destruccin de una instancia es enviando el viene dado por los nmeros de secuencia
mensaje destroy El mensaje que inicia la interaccin
Previamente, debe eliminarse todo link que generalmente no es numerado
exista con esa instancia mens1() 1: mens2()
:A :B
1: destroy()
: Empresa : Empleado 1.1: mens3() 2.1: mens5()
2: mens4() 2.2: mens6()

:C :D
Notacin Notacin
Nmeros de Secuencia (2) Mensajes Condicionales
:A :B :C :D
Un mensaje condicional es enviado
mens1()
mens2() nicamente si su guarda es satisfecha

mens3()
La guarda se muestra entre parntesis
rectos ([ ]) a la izquierda del mensaje
mens4()
mens5()
1: [p.edad>18] contratar()
mens6()
: Empresa p : Persona
Notacin Notacin
Colecciones Mensajes a Colecciones
Los multiobjetos de los diagramas de Un mensaje a una coleccin representa un
interaccin representan una coleccin de mensaje al objeto coleccin mismo
objetos de una cierta clase No un broadcast a todos los elementos
contenidos en l
1: e := create()
: Empleado : Empresa : Empleado
Coleccin de instancias 2: add(e)

de la clase Empleado
: Empleado
Notacin Notacin
Responsabilidad de Colecciones Responsabilidad de Colecciones (2)
Las colecciones sern tratadas como meros add(o:Tipo) Agrega la instancia o a la
coleccin del tipo Tipo
contenedores de objetos por lo que no remove(o:Tipo) Remueve la instancia o de la
tendrn otra responsabilidad ms que esa coleccin del tipo Tipo. No elimina la instancia
Proveern solamente operaciones que find(c:Clave):Tipo Retorna la instancia
con clave c de tipo Clave
permitan administrar los objetos contenidos
member(o:Tipo):Boolean Devuelve un
En general las interfaces de Diccionario booleano indicando si la instancia o de tipo Tipo
(add, remove, find, member, etc.) e existe o no en la coleccin
next():Tipo Devuelve el prximo elemento
Iterador (next, etc.) son suficientes para las en la coleccin. Se supone que la coleccin est
colecciones ordenada
Notacin Notacin
Resp. de Colecciones - Ejemplo Datatypes
t := totalSueldos() 1* [foreach]: e := next()
El procesamiento de datatypes
: Empresa : Empleado (construccin, envo de mensajes) no se
2* s := getSueldo()
e : Empleado
muestra grficamente: se utilizan notas
dp := obtenerDatosProducto():Set(DataProducto) 1* [foreach]: l := next()
: Venta : LineaDeVenta
Retorna un Set dp de los

DataProducto obtenidos 2* d := getDatos():DataProducto

t := totalSueldos() 1: t := getTotal()
Retorna un 2.1* p := getPrecio():Float
: Empresa : Empleado DataProducto d que 2.2* c := getCodigo():String
contiene el precio (p) y l : LineaDeVenta : EspProducto
cdigo (c) del Producto
Notacin
Datatypes (2) Reuso de Elementos de Diseo
Es posible iterar sobre los elementos de una Se busca reutilizar los elementos de
coleccin de datatypes: forall dt in ColDT diseo generados de una iteracin a otra
agregarDatos(colDP: Set(DataProducto)) 1* [forall dp in ColDP]: agregar(dp : DataProducto)
En particular: clases, operaciones y atributos
: Venta : LineaDeVenta Esto apunta a generar iterativamente el
diseo y no reinventar la rueda cada vez
Es posible acceder a los elementos de un El diseo debe ser consistente de una
datatype utilizando el operador . iteracin a otra. Es decir, si un elemento
agregar(dp: DataProducto) 1: agregarPrecio(dp.precio)
de diseo cambia, no puede quedar
: LineaDeVenta : EspProducto
informacin inconsistente en otra parte
del diseo
Errores Comunes
Suponer la existencia de links nunca
generados Programacin 4
Enviar un mensaje a un multiobjeto que
implique el procesamiento con todos los
objetos contenidos en l Diseo
No especificar qu sucede con mensajes Criterios de Asignacin de
que aparentan ser triviales Responsabilidades GRASP
Representar datatypes como instancias
Programacin 4 | Diseo: Diagramas de Comunicacin www.fing.edu.uy/inco/prog4 | 2010 | 26
Contenido Introduccin
Introduccin Un sistema orientado a objetos est
Responsabilidades compuesto de objetos que envan
Criterios GRASP mensajes a otros objetos para realizar
operaciones
Interfaces del Sistema
Para una misma operacin es posible
Fbricas
disear interacciones asignando
responsabilidades de diferentes formas
La calidad del producto resultante no es
la misma en todos los casos
Programacin 4 | Diseo: Criterios de Asignacin de Responsabilidades GRASP www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2 Programacin 4 | Diseo: Criterios de Asignacin de Responsabilidades GRASP www.fing.edu.uy/inco/cursos/prog4 | 2010 | 3
Introduccin (2) Responsabilidades
Malas elecciones pueden conducir a Una responsabilidad es una obligacin que
sistemas que sean frgiles y difciles de un tipo tiene
mantener, comprender, reutilizar y Estas obligaciones son entendidas en
extender trminos del comportamiento de los objetos
Existen criterios para la asignacin de Existen dos tipos bsicos de
responsabilidades que nos guan hacia el responsabilidades:
diseo de una buena solucin Responsabilidad de saber o conocer
Estos son los criterios GRASP Responsabilidad de hacer
Responsabilidades Responsabilidades
Saber/Conocer Hacer
Responsabilidades de objetos tpicas de Responsabilidades de objetos tpicas de
esta categora: esta categora:
Conocer datos privados Hacer algo por s mismos
Conocer a otros objetos Iniciar acciones en otros objetos
Saber cosas que pueda derivar o calcular Controlar actividades de otros objetos
Ejemplo: Una transaccin de un cajero Ejemplo: Una transaccin de un cajero
automtico es responsable de conocer su automtico es responsable de imprimirse a
fecha de realizada s misma
Responsabilidades Responsabilidades
Responsabilidades y Mtodos Resps. y Mtodos (2)
Una responsabilidad es tpicamente El mtodo asociado al punto de entrada generar
asignada a una clase siendo instancias de el resultado esperado en funcin de:
sta quienes efectivamente deben cumplir El estado del objeto implcito (la responsabilidad se
con la responsabilidad resuelve completamente en el punto de entrada)
El trabajo delegado a otros objetos
Para solicitar a una instancia que cumpla
Una combinacin de ambos enfoques

con una responsabilidad es necesario
enviarle un mensaje (i.e. invocarle una Delegar trabajo a otros objetos significa definir
operacin) sub-responsabilidades y asignarlas a ellos
Dicha operacin suele denominarse punto Esto causa que para resolver la responsabilidad
de entrada original se deba producir un interaccin entre un
conjunto de objetos
Responsabilidades
Diagramas de Comunicacin Criterios GRASP
Los diagramas de comunicacin son los Los GRASP son criterios que ayudan a
artefactos mediante los cuales se resolver el problema de asignar
expresarn las interacciones responsabilidades
Su propsito es ilustrar la asignacin de Sugieren:
responsabilidades y sub-responsabilidades 1. A quin asignar una responsabilidad cualquiera
2. A quin asignar algunas responsabilidades
Dan una pauta de cmo se debe particulares
implementar el punto de entrada 3. Aspectos a tener en cuenta al asignar una
Sin embargo NO intenta ser un responsabilidad para que la solucin presente
ciertas cualidades deseables
pseudocdigo para la operacin
Criterios GRASP (2) Criterios GRASP (3)
Expert (Tipo 1) Responsabilizar a quin tenga Controller ayuda a asignar la responsabilidad
la informacin necesaria
de manejar una operacin del sistema
Creator (Tipo 2) A quin responsabilizar de la
creacin de un objeto Expert tpicamente ayuda a asignar sub-
Bajo Acoplamiento (Tipo 3) Evitar que un responsabilidades
objeto interacte con demasiados objetos
Alta Cohesin (Tipo 3) Evitar que un objeto
Creator aplica cuando una responsabilidad
haga demasiado trabajo implica crear un objeto
No Hables con Extraos (Tipo 3) Asegurarse El resto se tiene en cuenta en todo momento
que un objeto realmente delega trabajo
Tpicamente para elegir la preferible entre
Controller (Tipo 2) A quin responsabilizar de
ser el controlador diferentes alternativas
Criterios GRASP Criterios GRASP

Controller Controller (2)
Sugerencia 1: Un controlador de tipo Faade provee
todas las operaciones del sistema:
Asignar la responsabilidad de manejar las Existe un nico controlador por sistema
operaciones del sistema a una clase que Recibe el nombre del sistema o de la organizacin
represente una de las siguientes opciones:
La organizacin o el sistema (faade controller)
Un controlador de casos de uso realiza las
Un manejador artificial de todas las operaciones
operaciones de un solo caso de uso:
de un mismo caso de uso (use-case controller) Existen tantos controladores como tantos casos
de uso
Reciben el nombre XXController siendo XX el
caso de uso asociado
Controller (3) Controller (4)
Ejemplo: Sugerencia 2:
Quin debe ser responsable de manejar un
evento del sistema como ingresarItem? Utilizar el mismo controlador para manejar
las operaciones del sistema de un mismo
Segn Controller estas seran las opciones:
caso de uso
Caja faade controller (representa al sistema)
Supermercado faade controller (representa a la
organizacin)
Esto es para poder mantener dentro de un
ProcesarVentaController use-case controller
mismo controlador el estado de la sesin
(representa un manejador artificial para el caso de De otra forma el estado quedara distribuido
uso considerado) en diferentes controladores

Discusin: En qu casos conviene elegir Discusin (cont.):
uno u otro tipo de controlador? Los controladores faade son adecuados
Un error muy comn al disear controladores cuando se tiene pocos casos de uso y una
es asignarles demasiadas responsabilidades poca cantidad de operaciones del sistema en
En este tipo de casos el controlador cada uno
presentara una baja cohesin y adems un Un controlador faade puede verse
alto acoplamiento desbordado de responsabilidades si manejase
Un controlador debera delegar trabajo a otros muchas operaciones del sistema de muchos
objetos mientras l coordina la actividad casos de uso
Discusin (cont.): Ejemplo CajaRegistradora
Cuando se tienen muchos casos de uso con
RealizarVentaHandler CrearInventarioHandler iniciarVenta()
muchas operaciones es conveniente optar por agregarProducto()
cancelarProducto()
controladores de casos de uso iniciarVenta()
agregarProducto()
crearInventario()
crearProducto() modificarCantidad()
terminarVenta()
Cada controlador manejara las operaciones del cancelarProducto() eliminarProducto()

caso de uso correspondiente, manteniendo alta su
modificarCantidad()
terminarVenta() vs. realizarPago()
cerrarCaja()
calcularTotales()
realizarPago() RealizarDevolucionHandler
cohesin CerrarCajaHandler
inicarDevolucion()
devolverProducto()
iniciarDevolucion()
terminarDevolucion()
Una desventaja que presenta este enfoque es que cerrarCaja()
devolverProducto()
terminarDevolucion()
liquidarDevolucion()
crearInventario()
si la cantidad de casos de uso es muy grande calcularTotales() liquidarDevolucion()
crearProducto()
entonces la cantidad clases de controladores eliminarProducto()
tambin lo ser Controladores de Caso de Uso Controlador Faade


Expert Expert (2)
Sugerencia: Ejemplo
Venta
fecha
hora
Asignar una responsabilidad al experto en
1
informacin: la clase que tiene o conoce la tiene
informacin necesaria para cumplir con la
1..*
responsabilidad * 1 EspProducto
describe
LineaDeVenta codigo
cantidad precio
descripcion
Quin es el responsable de conocer el total de una venta?

Expert (3) Expert (4)
Para asignar esa responsabilidad hay que Para asignar esa nueva responsabilidad hay
determinar qu informacin se requiere que determinar qu informacin se requiere
El subtotal de cada lnea de la venta La cantidad de productos y el precio unitario
Esta informacin slo puede ser obtenida por Esta informacin slo puede ser obtenida por
la venta pues es quien conoce cada lnea la lnea de venta pues es quien conoce la
La clase Venta es la experta en conocer el total cantidad y la especificacin del producto
Esto genera otro problema de asignacin de La clase LineaDeVenta es la experta en conocer
responsabilidades el subtotal
Quin es responsable de conocer el subtotal de Esto genera otro problema de asignacin
una lnea de venta? Quin es responsable de conocer el precio
unitario?

Expert (5) Expert (6)
Para asignar esa nueva responsabilidad hay Esta asignacin se ilustra en un diagrama
que determinar qu informacin se requiere
El precio unitario de un producto t := totalVenta() 1* [foreach]: l := next()
Esta informacin slo puede ser obtenida por : Venta : LineaDeVenta
la especificacin del producto pues tiene ese

Punto de entrada
dato como atributo de la interaccin
2* s := subtotal()
La clase EspProducto es la experta en conocer 2.1* p := getPrecio()
el precio unitario l : LineaDeVenta : EspProducto
Recordar que esto no pretende ser un pseudocdigo
Expert (7) Creator
La estructura necesaria para esta interaccin Sugerencia:
sera Venta Asignar a la clase B la responsabilidad de crear
fecha : Date
hora : Time
una instancia de la clase A en uno de los
totalVenta() : Real siguientes casos:
1 A est agregado en B
tiene
1..* A est contenido en B
EspProducto
LineaDeVenta * 1 B registra instancias de A
describe codigo : String
cantidad : Integer precio : Real B utiliza objetos de A en forma exclusiva
subtotal() : Real descripcion : String
getPrecio() : Real B es experto en crear instancias de A

Creator (2) Creator (3)
Crear instancias es una de las acciones Ejemplo:
ms comunes en un sistema orientado a Quin es el responsable de crear instancias
objetos de LineaDeVenta?
Es de utilidad disponer de un criterio Por Creator, se decide que la clase Venta es
general para la asignacin de la responsable de crear instancias de
responsabilidad de crear instancias LineaDeVenta
Realizndose en buena forma el diseo agregarProducto(cod,cant) 1: create(cant)
adquiere buenas cualidades como el : Venta : LineaDeVenta
bajo acoplamiento
Bajo Acoplamiento Bajo Acoplamiento (2)
Sugerencia: El acoplamiento es una medida de
Que tanto una clase est relacionada
Tiene conocimiento de
Asignar responsabilidades de forma tal que el
acoplamiento general se mantenga bajo O depende de otras clases
Una clase con bajo acoplamiento
depende de pocas clases
En cambio una con alto acoplamiento
depende de demasiadas clases

Bajo Acoplamiento (3) Bajo Acoplamiento (4)
Una clase con alto acoplamiento no es Formas comunes de acoplamiento entre
deseable ya que presenta los siguientes elementos X y Y pueden ser:
problemas: X tiene un atributo de tipo Y
Cambios en las clases en las que se X tiene un mtodo que referencia a una
depende fuerzan cambios locales instancia de Y. Esto puede ser porque:
Es difcil de comprender en forma aislada Tiene una variable local
Es difcil de reutilizar ya que requiere de la Tiene un parmetro formal
presencia de las clases de las que depende Retorna una instancia de tipo Y
X es subclase directa o indirecta de Y
Y es una interfaz y X la implementa
Bajo Acoplamiento (5) Bajo Acoplamiento (6)
Ejemplo: Ejemplo (cont.)
Se necesita crear un pago y asociarlo a la Una asignacin de responsabilidades tal
venta correspondiente producira la siguiente solucin
Quin es el responsable de esto? pagar() 1: create()
: Caja p : Pago
La caja registrara los pagos en el mundo real
2: asignarPago(p)
Por Creator la clase Caja es entonces un
candidato para ser responsable de crear los : Venta
pagos Sin embargo aqu se acopla a Caja con Pago

y a Venta con Pago (Caja ya estaba acoplada
a Venta)

Bajo Acoplamiento (7) Alta Cohesin
Ejemplo (cont.) Sugerencia:
Ya que la Venta esta acoplada al Pago, por
Bajo Acoplamiento podramos hacer que la
Venta cree el Pago, as Caja no estara Asignar responsabilidades de forma tal que
acoplada con Pago la cohesin general se mantenga alta
pagar() 1: pagar()
: Caja : Venta
1.1: create()
: Pago
Alta Cohesin (2) Alta Cohesin (3)
La cohesin es una medida de que tan Una clase con baja cohesin no es deseable
relacionadas estn entre s las ya que presenta los siguientes problemas:
responsabilidades de una clase Es difcil de comprender
Una clase altamente cohesiva tiene un Es difcil de reutilizar
conjunto de responsabilidades Es difcil de mantener
relacionadas y no realiza una gran Se ve afectada por cambios en forma constante
cantidad de trabajo Clases con baja cohesin tomaron
demasiadas responsabilidades que pudieron
haber delegado a otras clases

Alta Cohesin (4) Alta Cohesin (5)
Ejemplo: En conclusin una clase con alta
Es posible retomar el ejemplo anterior asignando cohesin:
la responsabilidad de crear un pago a la clase
Tiene un nmero relativamente pequeo de
Caja
operaciones (no realiza demasiado trabajo)
Considerndose en forma aislada (aparte del
problema del acoplamiento) no habra problema Sus funcionalidades estn muy relacionadas
en asignar la responsabilidad a la caja Clases as son ventajosas ya que son
Pero en un contexto ms global si se hace a la fciles de mantener, entender y reutilizar
caja responsable de ms y ms operaciones del
sistema resultara que se encontrara
sobrecargada y bajara su nivel de cohesin
No Hables con Extraos No Hables con Extraos (2)
Sugerencia: Lo que busca evitar es que un objeto gane
temporalmente visibilidad sobre un objeto
Asignar responsabilidades de forma tal que un
objeto desde un mtodo le enve mensajes indirecto
solamente a: Un objeto es indirecto respecto a uno dado si
l mismo (this o self) No est conectado directamente a ste
Un parmetro de un mtodo Existe un tercer objeto intermedio que est
Un atributo de this o self
conectado directamente a ambos
Un objeto contenido en una coleccin que sea un Ganar visibilidad sobre un objeto indirecto
atributo de this o self implica
Un objeto local Quedar finalmente acoplado a ste
Un objeto global Conocer la estructura interna del objeto intermedio

No Hables con Extraos (3) No Hables con Extraos (4)
Ejemplo: Ejemplo (cont.):
En caso de que la caja deba responder el La forma de devolver el monto del pago sera:
monto de un pago una solucin podra ser la
siguiente: mnt := montoPago() 1: p := getPago()
: Caja : Venta
1 captura 1 Venta 1 1
Caja paga Pago
fecha : Date
monto : Real 2: mnt := getMonto()
hora : Time
montoPago() : Real getMonto() : Real
getPago() : Pago
p : Pago
Un pago es un objeto indirecto para la caja (la venta es el intermedio)

En el mensaje 2 la caja habla con un objeto indirecto (un extrao)
Ejemplo (cont.): Ejemplo (cont.):
Un enfoque ms adecuado sera que la venta Realizada dicha modificacin la forma de
en lugar de devolver el pago completo devolver el monto del pago sera
devuelva la informacin del pago que la caja
necesita mnt := montoPago() 1: mnt := montoPago()
: Caja : Venta
Las clases Caja y Pago quedan incambiadas
1.1: mnt := getMonto()
Venta
fecha : Date
hora : Time
: Pago
montoPago() : Real
La caja ya no habla con un extrao

Ejemplo: Este criterio representa una buena sugerencia
dt := getDato() 1: b := getB()
En algunas situaciones particulares es
:X :A
preferible no tenerlo en cuenta
2: c := getC()
b:B
Estos casos corresponden a clases que se
encargan de devolver objetos indirectos para
3: d := getD()
c:C
que otros ganen visibilidad sobre ellos
4: dt := getDato() Estos casos presentan particularidades pero
d:D pueden ser considerados como violaciones a
No Hables con Extraos
X habla (y por lo tanto queda acoplado) con varios extraos
Instancias del Sistema
Dnde se encuentran las instancias
Complemento de Arquitectura generadas en el sistema?
Las instancias temporales (como el caso
del sistema con memoria) la informacin
la guarda el propio controlador
Las colecciones de objetos tambin
pueden ser una propiedad del controlador,
aunque existen otras alternativas
Instancias del Sistema (2) Interfaces del Sistema

En el caso en que el/los controlador/es Las operaciones del sistema realizadas por
mantenga/n las colecciones de instancias los controladores deben ser ofrecidas en
puede definirse a dicho/s controlador/es como interfaces
Singleton
Interfaces que contienen operaciones del
Un Singleton es una clase que permite una sistema se denominan Interfaces del
nica instancia de s misma con visibilidad Sistema
global hacia ella
En el caso que una coleccin de objetos sea
Enfoque para interfaces del sistema:
accedida nicamente a travs de otro objeto, Son realizadas por controladores (en la capa
este ltimo podr ser quien mantenga esa lgica)
coleccin Son utilizadas por habitantes de la capa de
presentacin
Interfaces del Sistema (2) Interfaces del Sistema (3)
C. Pres. C. Log.
Propsito de las interfaces del sistema: . .

Controlador
Formulario
Quebrar la dependencia entre operacionSistema1()
operacionSistema2()
Los elementos de la capa de presentacin . operacionSistema3()
.
que invocan operaciones del sistema

vs.
Los controladores de la capa lgica que las
implementan C. Pres.
Capa Logica
.
Usualmente cada controlador realiza una .
Formulario
interface Controlador
ISistema
interfaz del sistema (relacin 1:1) operacionSistema1()
operacionSistema2()
operacionSistema1()
operacionSistema2()
operacionSistema3() operacionSistema3()
.
.

El criterio para organizar estas interfaces es el En este tipo de casos:
mismo propuesto por Controller: Definir una interfaz para un controlador faade
Una interfaz para con todas las operaciones puede hacer que quede una sola interfaz
del sistema (faade) demasiado grande
Una interfaz por caso de uso Definir una interfaz por cada caso de uso para
Cuando se tienen pocas operaciones del definir controladores de caso de uso puede
sistema por caso de uso pero existen varios hacer que queden demasiadas interfaces
de ellos puede que sea conveniente optar por pequeas
una solucin intermedia a la propuesta por
Controller
La propuesta es: Ejemplo:
Agrupar casos de uso que estn Sistema de gestin de la informacin de un
relacionados entre s temticamente cine
Definir un controlador faade para cada Gran cantidad de casos de uso (15
uno de los grupos de casos de uso considerados para este ejemplo)
De esta forma existe un mini faade Muy pocas operaciones del sistema por caso
por cada uno de los grupos definido de uso (menos de 2 en promedio)
Alternativas:
As las cantidades de interfaces y 1 interfaz faade
operaciones del sistema por interfaz se 15 interfaces de caso de uso
equilibran Interfaces hbridas

Interfaz Faade interface
ISistema
Interfaces de Caso de Uso
crearPelicula() interface interface interface interface
getPeliculas() IAgregarUnaPelicula IAgregarUnaCartelera IConsultarDisponibilidad IVenderBoleto
getDatosPelicula() crearPelicula() crearCartelera() getDisponibilidadFuncion() getDisponibilidadFuncion()
eliminarPelicula() indicarFuncionPelicula() venderBoleto()
modificarPelicula() interface interface
interface
crearCartelera() IEliminarUnaPelicula interface IAgregarUnaReserva
ICancelarUnaVenta
indicarFuncionPelicula() getPeliculas() IConsultarCartelera crearReserva()
getBoletosVendidosFuncion()
getCartelera() getDatosPelicula() getCartelera() getDatosBoletoVendido()
getSalasProyectanPelicula() eliminarPelicula() eliminarBoleto()
interface
getPeliculasProyectadasEnSala() interface IEliminarUnaReserva
getFuncionesPelicula() interface IVerSalas interface
getReservas()
getDisponibilidadFuncion() IModificarUnaPelicula getSalasProyectanPelicula() getDatosReserva() IConsultarDatosVenta
crearReserva() getPeliculas() eliminarReserva() getBoletosVendidosFuncion()
getDatosReserva() getDatosPelicula() interface getDatosBoletoVendido()
eliminarReserva() modificarPelicula() IVerPeliculas interface modificarBoleto()
modificarReserva() getPeliculasProyectadasEnSala() IModificarUnaReserva
venderBoleto() getReservas()
getBoletosVendidosFuncion() interface getDatosReserva()
cancelarBoleto() IVerFunciones modificarReserva()
Demasiadas operaciones getDatosBoletoVendido() Demasiadas interfaces getFuncionesPelicula()
Interfaces del Sistema (10) Fbricas
Propuesta intermedia Las interfaces del sistema se definieron
como un mecanismo que permite quebrar la
interface
interface
ICartelera
interface
IReserva
interface
IVenta
dependencia de las clases de presentacin
hacia los controladores de la capa lgica
IPelicula
crearCartelera() getDisponibilidadFuncion() getDisponibilidadFuncion()
crearPelicula()
indicarFuncionPelicula() crearReserva() venderBoleto()
getPeliculas()
getCartelera() getReservas() getBoletosVendidosFuncion()
getDatosPelicula()
eliminarPelicula()
modificarPelicula()
getSalasProyectanPelicula()
getPeliculasProyectadasEnSala()
getDatosReserva()
eliminarReserva()
getDatosBoletoVendido()
eliminarBoleto()
Pero definir una interfaz no es suficiente
getFuncionesPelicula() modificarReserva() modificarBoleto()
para quebrar la dependencia entre dos
clases
Interfaz que contiene todas
las operaciones del sistema La forma en que una de las clases
de los casos de uso relativos
a la venta de boletos
(invocador) obtiene una referencia a la otra
(la que realiza la interfaz) determina si la
La cantidad de interfaces y de operaciones por interfaz es razonable dependencia se quiebra o no
Fbricas (2) Fbricas (3)

Ejemplo (clase Formulario) El problema es que para inicializar el
pseudoatributo de Formulario se menciona
class Formulario {
ISistema i; // pseudoatributo explcitamente a la clase Controlador
Formulario() {
Para solucionar este problema es necesario
i = new Controlador(); encontrar otra forma de incializar el
}
.
pseudoatributo con una instancia de
. Controlador
.
} Esa forma alternativa debe evitar que se
La clase Formulario igual depende de la clase Controlador!!!
mencione a la clase Controlador
Fbricas (3) Fbricas (4)
La forma de hacer eso es mediante una Ejemplo de funcionamiento
fbrica de objetos
1: c := getISistema() : ISistema
Una fbrica es un objeto que tiene la : Formulario : Fabrica
responsabilidad de crear instancias que
realicen una interfaz determinada 1.1: create()
En nuestro caso la fbrica crea instancias que 2: operacionSistema1()
realizan la interfaz ISistema : ISistema

c : Controlador
El invocador quedar acoplado a la fbrica

pero no depender del realizador de la El Formulario solicita a la Fabrica una instancia que realice la interfaz ISistema
interfaz Sin saber que es de clase Controlador, el formulario le invoca una operacin
Fbricas (5)
Estructura

interface Controlador
Programacin 4
ISistema
Formulario operacionSistema3() operacionSistema3()
Diseo
Fabrica
Visibilidad
getISistema() : ISistema
En caso de existir ms interfaces del sistema la misma Fbrica puede

encargarse de devolver instancias que las realicen
Programacin 4 | Diseo: Criterios de Asignacin de Responsabilidades GRASP www.fing.edu.uy/inco/cursos/prog4 | 2010 | 70

Introduccin Los diagramas de comunicacin ilustran
Visibilidad el envo de mensajes entre objetos
Notacin UML Para que un objeto pueda enviar un
mensaje a otro el primero debe tener
visibilidad sobre el segundo
En lo sucesivo se definirn distintos tipos
de visibilidad aplicables en UML y su
notacin
Programacin 4 | Diseo: Visibilidad www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2 Programacin 4 | Diseo: Visibilidad www.fing.edu.uy/inco/cursos/prog4 | 2010 | 3
Visibilidad Visibilidad por Atributo

La visibilidad es la capacidad de un objeto
Si existe esta visibilidad entre A y B
de tener una referencia a otro
entonces B es un pseudoatributo de A
Existen cuatro formas bsicas de que un
objeto A tenga visibilidad sobre otro B: Es una visibilidad permanente ya que
Por atributo: B es un pseudoatributo de A existe mientras A y B existan
Por parmetro: B es un parmetro de un Notar que si la multiplicidad mnima es
mtodo de A de cero la visibilidad no ser permanente
Local: B es declarado localmente en un
mtodo de A Es el tipo de visibilidad ms comn en
Global: B es visible en forma global sistemas orientados a objetos
Visibilidad por Atributo (2) Visibilidad por Parmetro
Ejemplo: Si existe esta visibilidad entre A y B

entonces B fue recibido como parmetro
1: e := create()
: Empresa : Empleado
en un mtodo de A
Es una visibilidad temporal ya que existe
2: add(e)
solamente en el alcance del mtodo
: Empleado Es el segundo tipo de visibilidad ms
comn en sistemas orientados a objetos
La coleccin de empleados es un pseudoatributo de la empresa
Visibilidad por Parmetro (2) Visibilidad Local
Ejemplo: Si existe esta visibilidad entre A y B

entonces B fue declarado como un
2: asignarCliente(c) 2.1: tomarPedido()
objeto local en un mtodo de A
: Empresa : Empleado c : Cliente
Tambin es una visibilidad temporal ya
1: c := find(x)
que existe en el alcance del mtodo
: Cliente
Es el tercer tipo de visibilidad ms
comn
El cliente c es recibido como parmetro por el empleado
Visibilidad Local (2) Visibilidad Local (3)
Formas de obtener este tipo de visibilidad: Formas de obtener este tipo de visibilidad:
Crear una instancia localmente y asignarla a Asignar el objeto devuelto por un mtodo a
una variable local una variable local
Ejemplo: 1: e := create() Ejemplo:
: Empresa : Empleado
2: asignarCliente(c) 2.1: tomarPedido()
: Empresa : Empleado c : Cliente

2: add(e)
1: c := find(x)
: Empleado
: Cliente
La empresa ve al empleado e localmente y puede mandarle mensajes La empresa ve al cliente c localmente y puede mandarle mensajes
Visibilidad Global Visibilidad en UML

Si existe esta visibilidad entre A y B entonces En UML es posible indicar el tipo de visibilidad
B es global a A gracias a la cual un mensaje es enviado
Es una visibilidad relativamente permanente 1: mens1()
ya que existe mientras A y B existan :A association

:B
Es la forma menos comn de visibilidad 2: mens2()
parameter :C
La forma ms obvia de lograr esta visibilidad
3: mens3()
es asignar una instancia a una variable global :D
local
Otra forma de obtenerla es mediante el patrn 4: mens4()

Singleton global
:E
Contenido
Introduccin
Programacin 4
Caso de Estudio
Guas para el Abordaje del Diseo
Diseo
Guas para el Abordaje del
Diseo
Programacin 4 | Diseo: Guas para el Abordaje del Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 1 Programacin 4 | Diseo: Guas para el Abordaje del Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2
Introduccin Caso de Estudio

Se desea abordar la etapa de diseo con Gestin de cuentas en bancos a travs
un enfoque sistemtico de ATMs (cajeros automticos):
Se presentarn pautas para organizar de A travs de una red de ATMs, los clientes
mejor forma la tarea acceden a sus cuentas sobre las cuales
realizan transacciones (depsitos y
Se ejemplificarn las mismas por medio retiros)
de un caso de estudio
Las cuentas pueden ser compartidas por
ms de un cliente
Caso de Estudio Caso de Estudio
Modelo de Dominio Caso de Uso
1
Cuenta-Cliente
< realizada sobre Nombre Retiro de Cuenta Actores Cliente
1..*
Cuenta Sinopsis El caso de uso comienza cuando el cliente
numero : int
saldo : float *
inserta su tarjeta en el cajero e ingresa su
1 *
clave de usuario. Tras validar al cliente, el
registra >
Transaccion sistema recibe el nombre del banco y el
Banco 1..* * ATM fecha : Date
nombre : string trabaja con > numero : int
hora : int nmero de cuenta para iniciar la transaccin
importe : float
1 *
terminada : bool de retiro correspondiente. El cliente ingresa el
* opera con >
monto que desea retirar de la cuenta y el
*
sistema realiza el dbito. Finalmente, el cliente
Retiro Deposito
1..* Cliente retira su tarjeta.
codigo : string

DSS con Memoria Descripcin de Operaciones
autenticarCliente (codCliente:String):bool
Valida la existencia del cliente
ingresarCuenta (nroCuenta:int,
Sistema
Cliente nomBanco:String)
Obtiene la cuenta nroCuenta del banco nomBanco
autenticarCliente(codCliente:String) : bool
sobre la cual se realizar la transaccin
El sistema recuerda
ingresarCuenta(nroCuenta:int, nomBanco:String) al Cliente (en el primer
ingresarMonto (monto:float)
Realiza la transaccin de dbito por el monto
mensaje) y la cuenta
(en el segundo mensaje)
ingresarMonto(monto:float)
indicado sobre la cuenta del cliente
finalizar ()
finalizar()
Finaliza la operativa del sistema
Caso de Uso (2) DSS con Memoria (2)
Nombre Consulta de Depsitos Actores Cliente
Sinopsis El caso de uso comienza cuando el cliente
inserta su tarjeta en el cajero e ingresa su clave
de usuario. Tras ingresar los datos de validacin Sistema
(igual que en el caso de uso Retiro de Cuenta), Cliente
el cliente indica el nombre del banco y el autenticarCliente(codCliente:String) : bool

El sistema recuerda
nmero de cuenta sobre la cual desea consultar al Cliente (en el primer
mensaje)
el total de depsitos (histricos). depositos(nroCuenta:int, nomBanco:String) : float
Posteriormente, el sistema calcula el total de finalizar()

depsitos histrico y lo devuelve. Finalmente, el
cliente retira su tarjeta.
Caso de Estudio
Descripcin de Operaciones (2) Guas para el Abordaje del Diseo
autenticarCliente (codCliente:String):bool El abordaje de la etapa de diseo puede
Misma operacin que en el DSS anterior realizarse sistemticamente
depositos (nroCuenta:int,
nomBanco:String):float Por ejemplo, considerando estos pasos:
Devuelve la suma de los montos de todos los 1. Organizar Operaciones
depsitos realizados en la cuenta nroCuenta del 2. Definir Ubicacin de Instancias
banco nomBanco
finalizar ()
3. Definir Colaboraciones
Misma operacin que en el DSS anterior 4. Disear Colaboraciones
Guas para el Abordaje del Diseo Guas para el Abordaje del Diseo
Organizar Operaciones Organizar Operaciones (2)
Definir los Controladores a utilizar Al definir Controladores, considerar
Definir las Interfaces del Sistema que Operaciones repetidas en casos de uso
contendrn las operaciones del sistema Memoria del Sistema
Organizar operaciones segn: Si un Controlador realiza una Interfaz
Afinidad temtica (segn dominio) del Sistema, asigna un mtodo a todas
Afinidad funcional (segn objetivos) las operaciones presentes en ella.
Casos de Uso
Definir la Fbrica de controladores
Ejemplo (Organizar Operaciones) Definir Ubicacin de Instancias
Algn concepto del dominio podra ser Diferenciar:
un Controlador?, ATM?, Banco? Las colecciones que pueden ser alojadas
interface en un controlador (ej: ATM, Banco)
IATM
+autenticarCliente() Las que sern accedidas nicamente a
+ingresarCuenta()
+ingresarMonto() travs de otra clase (ej: Cuenta accesible a
Una posible opcin ATMFactory
+depositos()
travs de Banco)
+finalizar()
+getIATM() : IATM
En caso de ser necesario, alojar
ATM separadamente una coleccin que sea
compartida entre varios controladores
Definir Colaboraciones Ejemplo (Definir Colaboraciones)
Una colaboracin realiza uno o ms casos Definir una sola colaboracin para
de uso ambos casos de uso es beneficioso ya
Agrupar casos de uso con cierta afinidad que estn relacionados
Comnmente afinidad temtica pero no
Consulta de
hay una regla estricta Depsitos
Retiro de
Cuenta
Definir una colaboracin por cada grupo de
casos de uso, asignndole un nombre
Priorizar las colaboraciones segn el Transacciones
impacto esperado sobre el diseo
Disear Colaboraciones Ejemplo (Disear Colaboraciones)
Disear cada colaboracin en orden de Cmo se asignan responsabilidades?
prioridad: Quin crea las transacciones?
Realizar diagramas de comunicacin para ATM?, Banco?, Cuenta?
las operaciones del sistema involucradas
Quin es el experto en calcular el total
Considerar (a) criterios de asignacin de de depsitos realizados?
responsabilidades, (b) decisiones
tomadas en iteraciones anteriores Banco?, Cuenta?, Cliente?
(consistencia) y (c) nuevos problemas de Qu visibilidades se necesitan?
diseo ATM Transaccin?, Banco Cuenta?,
Realizar el diagrama de clases de diseo Cliente Transaccin?, ATM Cuenta?
Ejemplo (Disear Colaboraciones) (2) Ejemplo (Disear Colaboraciones) (3)
Qu sucede con los tipos asociativos? Una posible solucin
Si poseen informacin relevante puede
ok := autenticarCliente(codCliente) 1: ok := member(codCLiente)
convenir mantenerlas
: ATM : Cliente
Cuenta-Cliente
ingresarCuenta(nroCuenta,nomBanco) 2: c := cuenta(nroCuenta) 2.1: c := find(nroCuenta)
Cliente 1..* 1..* Cuenta : ATM : Banco : Cuenta
Cliente 1..* 1..* Cuenta

a) ATM recuerda
la cuenta "c" 1: b := find(nomBanco)
Banco
Cliente 1 1..* 1..* 1 Cuenta
b) Cuenta-Cliente
Ejemplo (Disear Colaboraciones) (4) Ejemplo (Disear Colaboraciones) (5)
ingresarMonto(mnt) 1: ingresarMonto(mnt) 1.1: create(mnt) r := depositos(nroCuenta,nomBanco) 2: r := depositos(nroCuenta) 2.1: c := find(nroCuenta)
: ATM c : Cuenta r : Retiro : ATM b : Banco : Cuenta
1: b := find(nomBanco) 2.2: r := depositos()

c : Cuenta
1.2: add(r) Banco
finalizar() Retiro 2.2.1*[for each]: t := next()
: ATM Borra la informacin

temporal 2.2.2*: r1 := deposito()
Transaccion
t : Transaccion
Otras opciones r := suma de los r1
deposito() deposito()
Asociar la transaccin con el cliente : Retiro : Deposito Devuelve
Devuelve 0
el monto
Delegar las transacciones al banco
Contenido
Introduccin
Programacin 4
Diagrama de Clases de Diseo
Diseo
Diseo de la Estructura de
una Colaboracin
Programacin 4 | Diseo: Diseo de la Estructura de una Colaboracin www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2

La asignacin de responsabilidades ha Esta especificacin se realizar mediante
sido completada los diagramas de clases de UML
Estos diagramas:
La parte dinmica de la colaboracin que
Ilustran la estructura de la solucin
se est diseando ha sido determinada
Estn anotados con informacin de diseo,
Habiendo finalizado la construccin de los como por ejemplo operaciones y
diagramas de comunicacin es posible navegabilidades
especificar la parte estructural de la Al artefacto resultante lo llamamos
colaboracin Diagrama de Clases de Diseo (DCD) y
ser incluido en el Modelo de Diseo
Programacin 4 | Diseo: Diseo de la Estructura de una Colaboracin www.fing.edu.uy/inco/cursos/prog4 | 2010 | 3 Programacin 4 | Diseo: Diseo de la Estructura de una Colaboracin www.fing.edu.uy/inco/cursos/prog4 | 2010 | 4
Diagrama de Clases de Diseo Diagrama de Clases de Diseo (2)
Un Diagrama de Clases de Diseo especifica Elementos de diseo a incluir:
la estructura de una colaboracin Clases, asociaciones y atributos
Los elementos que contiene son Navegabilidades de asociaciones
Operaciones de clases y existencia de
representaciones grficas de algunos mtodos
elementos de diseo contenidos en el modelo Interfaces con sus operaciones
Los elementos a incluir son solamente Informacin acerca del tipo de los atributos y
aquellos que sean necesarios para solucionar de los valores devueltos por las operaciones
(incluyendo datatypes)
el/los caso/s de uso realizado/s por la
Generalizaciones entre clases o interfaces
colaboracin Dependencias entre elementos
Construccin de un DCD Construccin de un DCD (2)

Para la construccin de un DCD: Para la construccin de un DCD (cont.):
1. Identificar todas las clases que participan de la 5. Agregar la informacin de tipos a los atributos y
solucin de los casos de uso. Hacer esto operaciones
analizando los diagramas de comunicacin 6. Agregar las asociaciones necesarias para
2. Incluirlas en un el diagrama de clases permitir las visibilidades por atributo requeridas
3. Replicar los atributos de los conceptos en los diagramas de comunicacin
correspondientes en el Modelo de Dominio, 7. Agregar navegabilidades para indicar la direccin
agregando aquellos nuevos que sean necesarios de cada visibilidad por atributo
4. Agregar las operaciones correspondientes a cada 8. Agregar dependencias para reflejar los dems
clase analizando los diagramas de comunicacin tipos de visibilidades existentes
9. Agregar interfaces, fbricas y datatypes
Construccin de un DCD Construccin de un DCD
Informacin Previa (Dominio) Informacin Previa (Interacciones)
identificacion(pin,tarj) 3: asignarCliente(c) salir() 1: finalizar()
: ATM : Retiro : ATM r : Retiro

Cuenta 1 realizada sobre *
Transaccion
numero : Integer 2: c := find(tarj)
fecha : Date 2: add(r)
saldo : Real * hora : Time : Cliente
realiza * importe : Integer : Transaccion
Cliente
* terminada : Boolean
codigo : String
1
tiene seleccionarCuenta(cta) 1: asignarCuenta(cta,r) 1.1: c := find(cta)
*
opera con registra : ATM : Banco : Cuenta
Retiro Deposito
1 * 1.2: asignarCuenta(c)
1 tiene 1..* 1
Banco ATM r : Retiro
nombre : String numero : Integer
ingresarMonto(mnt) 1: ingresarMonto(mnt) 1.1: debitar(mnt)
: ATM : Retiro : Cuenta
Identificar las Clases e Ilustrarlas Agregar Operaciones y Mtodos

Pasos 1, 2 y 3 Paso 4
Transaccion ATM Transaccion
Banco ATM fecha Banco numero fecha
hora identificacion() hora
nombre numero nombre
importe seleccionarCuenta() importe
terminada asignarCuenta() terminada
ingresarMonto()
salir()
Retiro
Cuenta Retiro Cuenta
numero numero asignarCliente()
Cliente Cliente
saldo saldo asignarCuenta()
codigo codigo ingresarMonto()
debitar()
finalizar()
Agregar Informacin de Tipos Agregar Asociaciones y Navegabilidad
Paso 5 Pasos 6 y 7
ATM Transaccion ATM Transaccion
Banco numero : Integer fecha : Date Banco 1 * numero : Integer 1 * fecha : Date
identificacion(Integer,String)() hora : Time identificacion(Integer,String)() hora : Time
nombre : String nombre : String
seleccionarCuenta(Integer)() importe : Integer seleccionarCuenta(Integer)() finalizadas importe : Integer
asignarCuenta(Integer,Retiro)() terminada : Boolean asignarCuenta(Integer,Retiro)() terminada : Boolean
ingresarMonto(Integer)() ingresarMonto(Integer)()
salir() salir()
1
1..* 1
1..*
Retiro 1
Retiro
*
Cuenta Cuenta actual
numero : Integer asignarCliente(Cliente)() numero : Integer asignarCliente(Cliente)()
Cliente Cliente 1 *
saldo : Real asignarCuenta(Cuenta)() saldo : Real asignarCuenta(Cuenta)()
codigo : String ingresarMonto(Integer)() codigo : String ingresarMonto(Integer)()
debitar(Integer)() debitar(Integer)()
finalizar() finalizar()
1 *
Agregar Dependencias Agregar interfaces, fbricas y datatypes

Paso 8 Paso 9
ATM Transaccion
Banco 1 * numero : Integer 1 * fecha : Date
identificacion(Integer,String)() hora : Time
nombre : String
seleccionarCuenta(Integer)() finalizadas importe : Integer
asignarCuenta(Integer,Retiro)() terminada : Boolean
ingresarMonto(Integer)()
interface
salir()
1 IATM
1..* 1
ATM
ATMFactory
1..*
1 numero : Integer
Retiro
* identificacion(Integer,String)()
Cuenta +getIATM() : IATM
actual seleccionarCuenta(Integer)()
numero : Integer * asignarCliente(Cliente)() ingresarMonto(Integer)()
Cliente 1
saldo : Real asignarCuenta(Cuenta)() salir()
codigo : String ingresarMonto(Integer)()
debitar(Integer)()
finalizar()
1 *
Inclusin de Operaciones Inclusin de Operaciones (2)
Operacin create: Operaciones de acceso:
La operacin create es utilizada para la Son utilizados para obtener el valor de un
creacin de instancias atributo (get) o para modificarlo (set)
Esta forma es propia de UML e independiente Lo usual es declarar los atributos como
privados y necesitar este tipo de operaciones
de todo lenguaje de programacin
Sin embargo se las excluye de los diagramas
Este mensaje se corresponde con los
Por defecto se asume que un atributo tiene su
constructores de clases get y set asociado
Los constructores estn siempre presentes en Es posible indicar que para un atributo no se
las clases por lo que es comn omitirlos en los brindar la operacin set correspondiente
diagramas de clases de diseo aplicndole la restriccin {readOnly}
Inclusin de Operaciones (3) Inclusin de Colecciones

Operaciones de acceso (cont.) Las colecciones (tratadas como fuera
Ejemplo: la implementacin de la clase indicado) usualmente disponen todas de
Empleado contendr las operaciones
las mismas operaciones
calcularAportes()
asignarCliente() Por tal razn no aportaran mayor
getNombre()
Empleado
informacin al diagrama y es comn
nombre : String
setNombre() sueldo : Real {readOnly} omitirlas
getSueldo() calcularAportes() : Real

asignarCliente(Cliente)() La necesidad de una coleccin se deriva
de las multiplicidades
Diseo de la Estructura
Inclusin de Colecciones (2) Errores Comunes
Ejemplo No incluir las dependencias existentes
ATM
1 1
Transaccion
Omitir la definicin de los datatypes
numero : Integer
actual
fecha : Date No incluir interfaces, controladores ni
identificacion(Integer,String)() 1 *
hora : Time
importe : Integer
fbricas
seleccionarCuenta(Integer)()
ingresarMonto(Integer)()
finalizadas
terminada : Boolean
Sobrecargar el diagrama con
salir()
operaciones omitibles (create, set, etc.)
Incluir colecciones como clases
Un ATM tendr asociado:
Una sola transaccin actual
innecesariamente
Una coleccin de transacciones finalizadas
Contenido
Introduccin
Programacin 4
Patrones de Diseo
Singleton
Diseo Composite
Patrones de Diseo State
Observer
Programacin 4 | Diseo: Patrones de Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 2

Los diseadores expertos afirman que es casi Algo que los expertos saben es que no deben
imposible lograr un diseo flexible y reutilizable en resolver un mismo problema de una forma
el primer intento diferente cada vez
Los expertos logran buenos diseos mientras que En cambio, reutilizan soluciones que les dieron
los principiantes se ven abrumados por todas las buenos resultados en el pasado
opciones disponibles Cuando encuentran una buena solucin a un
Se requiere de mucho tiempo para que los problema la usan una y otra vez cada vez que el
principiantes aprendan de qu se trata un buen mismo problema se les presenta
diseo Esa experiencia es lo que los convierte en
Evidentemente los expertos tienen un expertos
conocimiento que los principiantes no
Programacin 4 | Diseo: Patrones de Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 3 Programacin 4 | Diseo: Patrones de Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 4
Introduccin (3) Introduccin (4)

Al desarrollar un sistema orientado a objetos un Problemas recurrentes
diseador enfrenta una serie de problemas a Cmo acceder a objetos sin acoplarse
resolver directamente a ellos? (Factory)
Muchos de ellos aparecern nuevamente en los Cmo acceder a un conjunto de interfaces por
siguientes proyectos independientemente del medio de un punto de acceso comn? (Facade)
dominio de cada uno de ellos Cmo restringir que una clase tenga una sola
Se detectan entonces problemas de naturaleza instancia y que se tenga visibilidad global hacia
muy similar entre s ella? (Singleton)
Que aparecen recurrentemente en el diseo de Cmo estructurar un conjunto de objetos con las
aplicaciones de diversos tipos (patrones) mismas operaciones en donde algunos de ellos
estn compuestos de otros? (Composite)
Introduccin (5) Patrones
Problemas recurrentes
Cmo puedo manejar diferentes estados de
comportamiento en un objeto? (State)
Cmo generar el esqueleto de un algoritmo y patrn sust 1 modo usual segn el cual
permitir variar algunos pasos del mismo? algo ocurre, se desarrolla o es hecho 2 cosa
(Template Method, Strategy)
Cmo controlar o uniformizar el acceso a un o forma que representa un ejemplo a copiar
objeto? (Proxy, Adapter)
Cmo reaccionar ante ciertos eventos ocurridos
en un objeto? (Observer)
Cmo acceder a las instancias de una coleccin?
(Iterator)
Patrones (2) Patrones de Diseo

Si fuera posible recordar los detalles de Un Patrn de Diseo sistemticamente da
un problema atacado en el pasado y la un nombre, motiva y explica un diseo
forma en que este fue solucionado, se general que se aplica a un problema de
podra reutilizar esa experiencia en lugar diseo recurrente en sistemas orientados a
de redescubrirla objetos
El propsito de los Patrones de Diseo Describe el problema, la solucin, cundo
es registrar esa experiencia para que aplicar la solucin y sus consecuencias
otros la aprovechen
Patrones de Diseo
Patrones de Diseo (2) Colaboracin Abstracta
Adems provee guas para su La solucin propuesta por un Patrn de
implementacin y ejemplos Diseo es una colaboracin abstracta (o
paramtrica) que resuelve un problema tipo
La solucin es un arreglo general de Dicha colaboracin es por lo tanto interpretada
objetos y clases que solucionan el como una plantilla de colaboracin
problema Si el problema concreto a resolver es
La solucin concreta es adaptada e compatible con el problema tipo se genera una
implementada a partir de ello para resolver colaboracin concreta a partir de la plantilla
el problema en un contexto particular Dicha colaboracin ser muy similar a la
plantilla y resolver el problema concreto
Patrones de Diseo Patrones de Diseo

Ejemplo Ejemplo (2)
El mecanismo de Fbricas utilizado para Tampoco es aplicable exclusivamente para
comunicar el Formulario con el Controlador no comunicar un elemento de la Capa de
es aplicable exclusivamente a este problema Presentacin con un Controlador
concreto interface Controlador El problema tipo que el mecanismo de
ISistema
Fbricas permite resolver es
Formulario operacionSistema3() operacionSistema3() Permitir visibilidad desde un consumidor hacia
proveedores concretos sin que el consumidor
Fabrica quede acoplado directamente a stos
getISistema() : ISistema
Ejemplo (3) Ejemplo (4)
La estructura de una colaboracin que Para el problema concreto determinamos
solucione el problema tipo puede ser: las siguientes correspondencias entre
parmetros Proveedor
Concreto1
clases del diseo y parmetros de la
colaboracin
operacion1()
interface
IProveedor
operacion2()
Clase Parmetro
operacion1()
Consumidor
operacion2() Proveedor
Concreto2
Formulario Consumidor
operacion1()
Fabrica Fabrica
operacion2()
Fabrica
ISistema IProveedor
getIProveedor() : IProveedor Controlador ProveedorConcreto1

Ejemplo (5) Ejemplo (6)
Para explicitar la correspondencia definida es Alternativa: indicar que ciertas clases
interface
desempean roles de un cierto patrn
posible embeber la estructura propuesta por el ISistema
operacionSistema1()
patrn en el diseo de la solucin operacionSistema2()
operacionSistema3()
(reemplazando los nombres de parmetros por IProveedor
los de las clases correspondientes) Formulario

Proveedor Controlador
Consumidor Concreto1
Esto conduce a un resultado como el Fabrica
mostrado originalmente
En general la estructura resultante es idntica Fabrica
nombre del Fabrica colaboracin
a la del patrn por lo que aumenta la patrn de diseo abstracta
complejidad del diseo final
Descripcin Descripcin (2)
La descripcin de un Patrn de Diseo est Descripcin (cont.)
organizada de la siguiente manera Estructura: diagrama de clases que ilustra
Nombre: la estructura de la colaboracin abstracta
Se utiliza para referenciar a un problema, su que soluciona al problema tipo
solucin y consecuencias en una o dos palabras Participantes: descripcin de las clases
Asignarle un nombre a un patrn incrementa el que forman parte de la estructura y sus
vocabulario de diseo permitiendo disear en un responsabilidades
nivel mayor de abstraccin
Interacciones: diagramas de interaccin
Problema: describe cundo utilizar el
que ilustran el funcionamiento de la
patrn, explica el problema tipo y su
colaboracin abstracta
contexto

Descripcin (3) Sugerencia
Descripcin (cont.) Comprender el detalle de la colaboracin
Consecuencias: Comentarios, propuesta por un patrn es fundamental
discusiones, sugerencias y advertencias para su aplicacin
que permitan entender e implementar el Tan importante como esto es comprender
patrn El problema tipo
La estructura e interacciones conforman la El contexto de aplicabilidad de un patrn
colaboracin abstracta que soluciona el Es de muy poca utilidad conocer la solucin
problema tipo a un problema desconocido o que no
sabemos reconocer
Patrones de Diseo
Sugerencia (2) Singleton
Conocer las consecuencias de la aplicacin Problema Tipo:
de un patrn es tambin fundamental
Asegurar que una clase tenga una sola
Aplicar la solucin abstracta propuesta a un
instancia y proveer un acceso global a ella
problema concreto puede no ser siempre
adecuado
Esto depende de las caractersticas Aplicabilidad:
particulares del problema concreto Debe existir una nica instancia de una clase
Por ejemplo: En ocasiones la cantidad de Dicha instancia debe ser accesible por
clases puede quedar demasiado grande cualquier cliente de la clase
Singleton (2) Singleton (3)

Estructura Interacciones
Singleton
-instancia : Singleton
1: s := getInstancia()
-Singleton()
+getInstancia() : Singleton : Cliente Singleton
+operacion()
Participantes 2: operacion()
1.1: [s no existe] create()
Singleton: provee una operacin de clase s : Singleton
(getInstancia()) que permite acceder a
la nica instancia
Singleton (4) Composite
Consecuencias Problema Tipo:
Se provee acceso controlado a una nica Componer objetos en estructuras arborescentes
instancia para representar jerarquas de objetos
Se permiten variantes en las que se vare el compuestos y tratar uniformemente los mismos.
nmero mximo de instancias
Un cliente puede liberar la memoria de la instancia Aplicabilidad:
Derivar una clase Singleton resulta complejo Se debe representar una jerarqua de objetos
donde algunos de ellos se componen de otros de
Aplicaciones la misma jerarqua
Las fbricas y manejadores suelen ser singleton Se desea que los clientes ignoren las diferencias
entre objetos compuestos y objetos primitivos, y
Algunos controladores tambin los traten uniformemente
Composite (2) Composite (3)

Estructura Participantes
Componente
Componente:
*
Cliente Operacion()
hijos
Declara el conjunto de operaciones comnes a los
Agregar(Componente)
Remover(Componente) objetos en la jerarqua e implementa el comportamiento
DarHijo(int) comn por defecto
Permite acceder y manipular los componentes hijo, y
opcionalmente los componentes padre
Hoja Compuesto
padre
Hoja:
Define el comportamiento de los objetos primitivos en la
Operacion() Operacion()
Agregar(Componente)
composicin
forall g in hijos
Remover(Componente)
g.Operacion()
DarHijo(int)
Participantes (cont.) Interacciones
Compuesto: Operacion() Operacion()
Procesa
: Componente : Hoja
Define el comportamiento de los objetos compuestos, el pedido
delegando a sus hijos el comportamiento relacionado

con ellos Operacion() 2*: Operacion()
Mantiene una referencia a sus componentes hijo : Compuesto c : Componente
Cliente:
Manipula los objetos de la composicin a travs de una 1*: [for each] c :=next()
instancia Componente : Componente
Compuesto puede pre/post procesar informacin al invocar a sus hijos.

Adems, no tiene porqu invocar a todos sus hijos.

Consecuencias Ejemplo
El cliente manipula objetos de la jerarqua sin Editor de figuras que permite agruparlas y
discriminar entre objetos primitivos y objetos moverlas conjuntamente
compuestos (elimina lgica condicional) Figura *
-x : int
Es fcil agregar nuevos componentes a la -y : int
jerarqua sin necesidad de modificar el cdigo +mover(in x : int, in y : int)
del cliente
Dificulta restringir el tipo de los objetos hijo de
Cuadrado Crculo FiguraCompuesta
un objeto compuesto
+mover(in x : int, in y : int) +mover(in x : int, in y : int) +mover(in x : int, in y : int) 0..1
State State (2)
Problema Tipo: Estructura
Permitir que un objeto vare su comportamiento 1
Contexto Estado
cuando su estado interno cambie. El objeto
parecer haber cambiado de clase solicitud() estado evento()
Aplicabilidad:
El comportamiento de un objeto depende de su EstadoConcreto1 EstadoConcreto2
{
estado y debe cambiar su comportamiento en estado.evento();
tiempo de ejecucin dependiendo de ese estado } evento() evento()
Las operaciones de un objeto tienen fragmentos

condicionales dependientes de su estado No se incluyen las dependencias
State (3) State (4)

Participantes
Interacciones
Contexto:
Es la clase de objetos cuyo comportamiento vara al solicitud() 1: s := evento()
cambiar el estado interno c : Contexto
: EstadoConcreto1
Mantiene una referencia a un estado concreto [Estado1]
Delega el comportamiento variable al estado actual

2: become 1.1: s := create()
Estado:
Generaliza los diferentes estados concretos del Contexto c : Contexto
: EstadoConcreto2
EstadoConcreto: [Estado2]
Cada una de estas clases implementa un

comportamiento particular del Contexto que sea
dependiente del estado El Contexto, estando en Estado1, al recibir una solicitud cambia a Estado2
State (5) State (6)
Consecuencias Consecuencias (cont.)
Sin Garbage Collector es necesario asignar a Es simple agregar nuevos estados
alguien la responsabilidad de eliminar, luego de Sin embargo es necesario modificar estados
una transicin, la instancia que representa el concretos existentes para incluir transiciones al
estado nuevo
estado anterior
Existen diferentes variantes en la implementacin
Los estados concretos pueden tener estado propio de las transiciones
Si no lo tienen pueden ser diseados como El Contexto puede pasarse como parmetro en los
singletons eventos
En casos en que el Contexto tiene muchos Permite eliminar la lgica condicional del Contexto
estados la cantidad de clases (a causa de los El estado concreto actual puede usarse para
estados concretos) puede ser muy grande determinar el estado del Contexto
State (7) Observer

Ejemplo Problema Tipo
Puerta automtica controlada por control Definir una dependencia 1-n entre objetos, de
remoto de un solo botn forma que cuando uno cambie de estado todos
Control los dependientes sean notificados
boton / m.cerrar() Motor Aplicabilidad
abrir() Cuando un cambio en un objeto requiere
Abierto Cerrado
cerrar()
cambiar otros y no se desea saber cuales
Motor maneja el motor Cuando un objeto debe notificar otros
boton / m.abrir() que abre y cierra la puerta objetos de diferente naturaleza y sin estar
acoplado a ellos
Observer (2) Observer (3)
Participantes
Estructura
Subject
Subject
* interface Dispone de informacin que es de inters para
Observer
agregar(Observer)() otros objetos
eliminar(Observer)() observers notificar()
modificar() Registra un conjunto de objetos interesados y
los notifica cuando lo considera necesario
Observer Observer
{ Concreto1 Concreto2 Observer: declara la operacin por la cual
for each o in observers { los interesados son notificados
o.notificar(); notificar() notificar()
} Observer Concreto: un interesado en los
}
avisos que el Subject tenga para enviar
Interacciones agregar() Interacciones modificar()

1: agregar(o)
o : ObserverConcreto1 : Subject modificar() 1* [foreach]: o := next()
: Subject : Observer
1.1: add(o)
2*: notificar()
o : ObserverConcretoN
: Observer :Observer
Recordar: realiza la interfaz Observer
Consecuencias Consecuencias (cont.)
No existe acoplamiento entre el Subject y Por defecto, el orden de notificacin es
los observadores concretos aleatorio
Este mecanismo es aplicable a la La notificacin es secuencial por lo que se
aguardar a que cada observador procese
realizacin de broadcasts la notificacin
Cambios inesperados en el Subject por La notificacin puede llevar parmetros
parte de un observador concreto puede En casos en que un observador observe a
causar notificaciones en cascada hacia los mas de un Subject a la vez puede ser
otros observadores concretos necesario que ste se identifique al
momento de notificar
Patrones
Sugerencias
Pasos a seguir
Analizar las caractersticas del problema a resolver
(Aplicabilidad)
Determinar si existe algn patrn de diseo que
pueda ser aplicado Implementacin
Aplicar la solucin propuesta por el patrn en el GeneracindeCdigo
diseo existente (Estructura e Interacciones)
Errores comunes
Aplicar un patrn cuando no estn dadas las
condiciones para ello, porque no se entendi bien el
problema
Programacin 4 | Diseo: Patrones de Diseo www.fing.edu.uy/inco/cursos/prog4 | 2010 | 49
Introduccin Propsito:realizarlaimplementacindeuna
ImplementacindeunaColaboracin: partedeldiseo(unacolaboracin)
ImplementacindelaEstructura Elresultadoescdigofuenteenlaformade
ImplementacindelaInteraccin ElementosdeImplementacin
Sugerencias Unatareadeimplementacinseenfocaen
obtenerciertafuncionalidad(alimplementarla
realizacindeuncasodeuso)queimplicala

implementacindediferenteselementosde
diseoquecontribuyanadichafuncionalidad
Programacin4Curso2013 Implementacin:GeneracindeCdigo 2 Programacin4Curso2013 Implementacin:GeneracindeCdigo 3
ImplementarlaEstructura
ImplementacindeunaColab.
ImplementarInterfaces
Paraimplementarunacolaboracin(querealice Lasinterfacesseimplementandirectamentea
caso/sdeuso): partirdelDCD
Implementarlaestructuradelacolaboracin
Lasoperacionesseobtienendelapropia
Implementarinterfaces
Implementarclases
especificacindelainterfaz
Implementaratributos Advertencia:algunoslenguajesdeprogramacin
Implementaroperaciones

noproveenunaconstruccinparaimplementar
Implementarrelaciones
Implementargeneralizaciones directamenteinterfaces:
Implementarrealizaciones Enesoscasossesueleimplementarunaclaseabstracta,sin
Implementarasociaciones atributosycontodassusoperacionesabstractas
Implementarlasinteraccionesdelacolaboracin
Implementarmtodos
ImplementarlaEstructura ImplementarlaEstructura
ImplementarInterfaces(2) ImplementarClases
Laimplementacindelasclasessehaceenformadirecta
class IControladorUsuario { // interfaz

public: apartirdelDCD
virtual bool login(string usuario, string password) = 0; Loslenguajesdeprogramacinorientadosaobjetos
virtual void logout() = 0;
virtual bool actualizarPassword(string passwordAntiguo, incluyenunaconstruccinparaestefin(laclase)
string passwordNuevo) = 0; Losatributosyoperacionesseobtienendelapropia
virtual set<DataPermiso> permisos() = 0;
virtual set<DataUsuario> getAmigos() = 0;
especificacindelaclase
virtual DataUsuario getPerfil() = 0; Seincluyenlosconstructoresydestructor
// ...
Tambinlasoperacionesdeaccesoy/omodificacindelos
virtual ~IControladorUsuario(){}; // virtual y vaco atributos
};
ImplementarClases(2) ImplementarRelaciones
class Tweet {
private: Lasrelacionesentreelementosdediseo
Usuario *usuario;
string contenido; empleadasson:
public:
// constructores Generalizaciones
Tweet(Usuario *u, contenido c);
Realizaciones
// mtodos de acceso
Usuario getUsuario(); Asociaciones
string getContenido();
Dependencias
// otros mtodos
void agregarHashtag(string hashtag);
/* ... */
private:
static set<string> parsearHashtags(string s);
/* ... */
public:
virtual ~Tweet();
};

RelacionesGeneralizaciones
RelacionesRealizaciones
Lasgeneralizacionesseobtienendirectamentedel Lasrealizacionestambinseobtienendirectamentedel
DCD DCD
Loslenguajesdeprogramacinorientadosaobjetos Loslenguajesdeprogramacinquenoproveen
proveenunaconstruccinparaesto interfacestampocoproveenrealizaciones
Enladeclaracindelaclaseseespecificala(s)interfaz(ces)
Enladeclaracindelaclaseseespecificasuancestro querealiza
(muchoslenguajespermitenslouno)
EnC++seutilizaunageneralizacin
Ejemplos: Ejemplos:
Java: class Jornalero extends Empleado Java:class ControladorUsuario implements ControladorUsuario
C++: class Jornalero: public Empleado C#:class ControladorUsuario : ControladorUsuario
C#: class Jornalero: Empleado C++:class ControladorUsuario : public ControladorUsuario
RelacionesAsociaciones RelacionesAsociaciones(2)
Loslenguajesdeprogramacingeneralmenteno SedefineunpseudoatributoenAsolamentesilaasociacin
proveenunaconstruccinespecficaparala esnavegablehaciaB
implementacindeasociaciones EltipodeunpseudoatributoparaAdependedelaclaseB,
ParaqueunaclaseApuedaestarasociadaaunaclaseB perotambindelamultiplicidadenelextremodela
asociacindelladodeB
sesueleincluirunatributoenA
Sedistinguendoscasosdependiendodelmximodedicha
Esteatributonopertenecealconjuntodeatributosdefinidos multiplicidad:
en el diseo por lo que se lo denomina pseudoatributo Sielmximoes1(0..11)
AtravsdelpseudoatributounainstanciadeApuede ElpseudoatributoesdetipoB*
mantenerunareferenciaaotradeByasimplementar Delocontrario(0..*;1..*;etc.)
Elpseudoatributoesdetipocoleccin(ICollection;set<B>;
ellink map<T,B>,etc.) dependiendodelasnecesidadesdenavegacin

RelacionesAsociaciones(3) RelacionesAsociaciones(4)
Caso1: Caso1(cont.):
0..1 *
Unapersonapuedetenerunareferenciaaunaempresa
Empresa trabaja en Persona
RUC : Long nombre : String

empleados

EjemploenC++
class Persona { Nombre=JCDenton RUT=211035721004
private:
String nombre;
Empresa * empresa; // pseudoatributo e
public:
... p
};
RelacionesAsociaciones(5) RelacionesAsociaciones(6)
Caso2: Caso2(cont.):
Empresa 0..1 * Persona
Unaempresatieneunacoleccindereferenciasapersonas
trabaja en

empleados e>empleados

EjemploenJava nombre=JC Denton

class Empresa { RUT=211035721004
private long RUC;
private Lista *empleados; // pseudoatributo nombre=Artyom
...
};
e

RelacionesAsociaciones(7)
RelacionesDependencias
Caso2(cont.): Lasdependenciassedeclaranenladefinicindeun
Laeleccindelaestructuradedatosqueimplementela elementoparatenervisibilidadsobreotros
coleccinserealizaenfuncindesimplicidad,disponibilidad, EstosehacecuandoenelDCDexisteunadependencia
requerimientosdeeficiencia,etc. desdeunelementoAhaciaotroB
Encasosenqueelextremodeasociacintengaaplicadala
Unaasociacinnavegable,unageneralizacinyunarealizacin
restriccin{ordered}esnecesarioutilizarunacoleccinque
sontambinformasdedependencia
permitaordenamiento
Muchosambientesdeprogramacincuentanconbibliotecas
EnC++seutiliza#include
declasescondiferentestiposdecoleccionespredefinidas.En EnJavaseutilizaimport
C++estSTL EnC#seutilizausing

ImplementarlasInteracciones
ImplementarlasInteracciones
ImplementarMtodos
Laimplementacindelaestructuraconduceala Undiagramadecomunicacinnotienecomo
definicindeloselementosdediseojuntoconsus objetivoservirdepseudocdigo
relaciones
Sinembargogeneralmenteilustralalgicageneralde
Lasclasesincluyensusoperacionesperonolos
lasoperaciones
mtodosasociados
Estosignificaquenoexisteninvocacionesimplementadaspor Alimplementarelmtodoasociadoalaoperacin
loqueannohaycomportamiento op()enunaclaseA:
Apartirdelosdiagramasdeinteraccinseextrae Sebuscaeldiag.decomunicacinqueincluyaunmensaje
informacinparaimplementarlosmtodos op()llegandoaunainstanciadeA
Lainteraccinanidadaenesemensajedeberaresultarde
ayudaparaimplementarelmtodo

ImplementarlasInteracciones ImplementarlasInteracciones
ImplementarMtodos(2) ImplementarMtodos(3)
Ejemplo: Ejemplo(cont.):
class Venta {
private:
t := totalVenta() 1* [foreach]: l := next() ICollection *lineas;
public:
: Venta : LineaDeVenta float totalVenta();
virtual ~Venta();
};
2* s := subtotal() float Venta::totalVenta() {

float total = 0;
2.1* p := getPrecio() for(IIterator *it = lineas->getIterator(); it->hasCurrent(); it->next()) {

LineaDeVenta *ldv = dynamic_cast<LineaDeVenta *>(it->getCurrent());
l : LineaDeVenta : EspProducto total += ldv->subtotal();
}
return total;
}
Para implementar el mtodo asociado a totalVenta() observamos la interaccin
anidada en el mensaje (en el primer nivel) en el diagrama de comunicacin
Antesdeimplementarunaclasedesdeceroes Ordendeimplementacindelasclases:
recomendableconsiderarsicdigoexistente Lasclasesdebenserimplementadascomenzandoporlas
puedeserreutilizadooadaptado menosacopladasyfinalizandoporlasmsacopladas
Deestaformalasclasesvandisponiendodetodoslos
Comprenderenqulugardelaarquitectura elementosnecesariosparasuimplementacin
encajalaimplementacinayudaa: Estopermitequealterminardeimplementarunaclasese
Identificaroportunidadesdereuso
puedatestearinmediatamente
Asegurarqueelcdigonuevoseacoherenteconeldel
restodelsistema

Contenido
Introduccin
Referencias
ObjetosCompartidos
CopiadeObjetos
Implementacin
DestruccindeObjetos
ManejodeObjetos

Programacin4Curso2013 Implementacin:ManejodeObjetos 2
Introduccin Referencias
Losobjetossonmanipuladosatravsdereferencias Entiempodeejecucinlosobjetosnoson
Dependiendodecmoloslenguajesde alojadosenelstacksinoenelheap
programacinlasimplementenaplicanciertas Laformadeaccederaunobjetoesmediante
consideracionestantoalamanipulacincomoala referencias
destruccindeobjetos
Unareferenciaesunavariable(tipada)quees
Laidentidadrequierequelosobjetossean
compartidos alojadaenelstack(oenelheapsiestdentrode
Estohacequelascopiasnecesitenserexaminadas
unobjeto)talque
endetalle Noidentificaaningnobjeto(void)
Identificaaunobjetoparticulardeunadeterminada
clase(attached)
Programacin4Curso2013 Implementacin:ManejodeObjetos 3 Programacin4Curso2013 Implementacin:ManejodeObjetos 4
Referencias(2) Referencias(3)
Ejemplo: Enalgunoslenguajesdeprogramacinlas
referenciasseimplementanexplcitamente
EnC++lasreferenciasseimplementanmediantepunteros
ClaseA *aPtr;
// referencia a un objeto de clase A
...
23A8 23A9 23AA 23AB 23AC 23AD 23AE 23AF ClaseA aObj;
Heap // variable en el stack
Stack
Referencias(4) Referencias(5)
Otroslenguajesmanejanreferenciasenforma Hacerqueunareferenciaseavoid
implcita EnC++:a = NULL
EnJavayC#:a = null
EnJavayC#noesposibledefinirobjetosenelstacksino
nicamentereferencias Hacerqueunareferenciaseaattached(encualquiera
delostreslenguajes)
ClaseA a; Crearunobjetoyadjuntarlareferenciaal
// a es una referencia a un objeto ClaseA *a = new A(); // en el heap
// de ClaseA y no un objeto ClaseA *b = null;
Adjuntarlareferenciaaunobjetoobtenidoatravsdeotra
referencia
a = b;
Asignacin de referencias (punteros)
ObjetosCompartidos ObjetosCompartidos(2)
Ensistemasorientadosaobjetosesusualqueun Ejemplo: Perez
objeto sea conocido por otros varios objetos

Laidentidadrequierequedichosobjetos : Cliente
referencienalmismoobjetoynoacopiasdel V439
Gonzalez
Eso implica que el objeto ser compartido por
otros
: Vendedor : Cliente
Estoselograteniendoencadaobjetounareferencia
alobjetocompartido Rodriguez
Los tres clientes comparten
el mismo vendedor
: Cliente
CopiadeObjetos CopiadeObjetos(2)
Laidentidadylanecesidaddecompartirobjetoshaceque Endeterminadassituacionesesaceptablelacopia
engeneralnoseacorrectocopiarobjetos deobjetos
Recordarqueunacopiadeunobjetoesotroobjetoque Distinguiremostrescasos:
luegodelacopiatienepropiedadesigualesalasdeloriginal Objetosqueimplementandatavalues
Apartirdelacopiaamboselementosevolucionan Objetosquesoninstanciasdeclasesdeldiseo
independientemente Objetosquerepresentancolecciones
Asuvezdistinguimosdosenfoquesderealizar
copiasdeobjetos:
Copiaplana
Copiaenprofundidad

CopiadeObjetos(3) CopiadeObjetos(4)
Copiaplana: Copiaenprofundidad:
Suresultadoesunobjetoexactamenteigualaloriginal, Elobjetoresultanteesexactamenteigualaloriginal,salvolas
incluyendosusreferencias referencias
Ejemplo: Ejemplo:
1234 1234 1234 1234
Original Copia Los objetos referenciados Original Copia

La copia es 100%
son copiados en profundidad
igual al original
XXX XXX XXX
CopiadeDataValues: CopiadeObjetos:
AlgunosDataTypesdebenserimplementadosmediante Losobjetossitienenidentidad
clasesporlocualsusinstanciassernformalmenteobjetos Encasoderequeriraunodesdemsdeunlugarsedebe
Estosobjetossepuedencopiardadoque compartirlo(noesaceptablecopiarlo)
Notienenidentidad(yaquesondatavalues) ComoreglageneralNOsedebecopiarobjetos
Sedeseadisponerdeunejemplardiferenteencadalugardondese Existencasoscontroladosdondeesposiblerealizarcopiasde
lorequiere
objetos
Lacopiadedatavaluesserealizaenprofundidad


CopiadeColecciones: CopiadeColecciones(cont.)
Elcasodelascoleccionesesparticularporquepueden Lacopiadecoleccionesdeobjetosserealizaenforma
involucrar plana
Unaestructuradedatos(sinidentidad) Ejemplo:
Objetos(conidentidad) original
Lascoleccionesdedatavaluessetratancomoelcasodelos
datavalues(enprofundidad)
Encasosenqueseanecesariootracoleccinigualalaoriginal XXX YYY ZZZ
sedebecopiarsolamentelaestructuradedatos(plana)
copia
DestruccindeObjetos DestruccindeObjetos(2)
Losobjetosalojadosenelheappermanecenall GarbageCollector:
hastaqueelprogramatermina(adiferenciade Formapartedelambientedeejecucindellenguajede
aquellosalojadosenelstack) programacin
Correenparaleloconelprograma
Cuandounobjetoyanoesdeutilidadselosuele Buscaobjetosenelheaptalesquenoexistaningunareferencia
retirardelheapparaliberarlamemoria adjuntaaellos
Cuandoencuentraunobjetotalloeliminayliberalamemoria
Existendosenfoquesparaello: questeocupa
Automtico,medianteelllamadoGarbageCollector(Java,C#) Permitealprogramadorsolicitarmemoriasintenerque
Manual(C++) preocuparse por devolverla
HaylibrerasqueimplementanGarbageCollectionenC++(libgc)

DestruccindeObjetos(3) DestruccindeObjetos(4)
DestruccinManual: DestruccinManual(cont.)
Esteenfoqueesmscomplejoydelicado Memoriainaccesible:estoocurrecuandounobjetono
Requierequeelprogramadorexplcitamenteliberela tieneningunareferenciaadjuntaal
memoriaocupadaporunobjeto Ejemplo:
Problemasfrecuentes
Memoriainaccesible void memLeak(){
Empleado * e;
Referenciascolgantes
e = new Jornalero();
}
La nica referencia adjunta al jornalero recin creado se perdi cuando se

llega a la llave de cierre. En consecuencia el jornalero queda inaccesible.
DestruccindeObjetos(5) DestruccindeObjetos(6)
DestruccinManual(cont.) Enfoquesparaladestruccinmanualdeobjetos
Referenciascolgantes:estoocurrecuandounobjetoes Desarrollarunaestrategiaparticular:enfuncindelas
compartidoysedestruyeatravsdeunadelasreferencias particularidades del problema el programador sabe
Ejemplo: cundoycmoeliminarunobjetoenformasegura
(tpicamentequiencreaelobjetoserquienlodestruya).
Empleado *colgante(){ Hayprogramasquepermitendetectarmemoryleaks,
Empleado * e1, *e2; referenciascolgantesperosonmuylentos(valgrind)
e1 = new Jornalero(); Nodestruirobjetos:Noesaplicableensistemasdondese
e2 = e1; creeunagrancantidaddeobjetos
delete e2;
Utilizarcontadoresdereferencias:cadaobjetocontiene
return e1;
}
uncontadordereferenciasadjuntasal.Nosolucionalos
Moraleja: cuidado al destruir objetos compartidos!!
ciclosdereferencias.
Contenido
Introduccin
ColeccionesdeObjetos
ColeccionesGenricas
Implementacin RealizacindeunaColeccinGenrica
Iteradores
Colecciones
Diccionarios
Bsquedas
ContenedoresSTL
Programacin4Curso2013 Implementacin:Colecciones 2
Laimplementacindeasociacionesusualmente Sedistinguendostiposdecoleccionesdependiendodesi
loselementoscontenidosposeenunaclavequelos
requieredelusodecoleccionesparapermitirlinks identifiqueono
conmuchosobjetos Ladefinicindelascoleccionesautilizarenla
Eltipodeloselementosdelascolecciones implementacinseestudiarincrementalmente
dependedelaclasecorrespondientealextremode Secomenzardefiniendounacoleccingenricade
elementossinclavelacualseraumentadapara:
asociacinnavegable
Permitiriteracionessobresuselementos
Portratarlasdemanerauniformestascomparten Soportarelusodeclaves
unamismaestructuraquepuedeserreutilizada Soportardiferentestiposdebsquedas
paragenerarlas
Programacin4Curso2013 Implementacin:Colecciones 3 Programacin4Curso2013 Implementacin:Colecciones 4
ColeccionesdeObjetos
Lascoleccionesdeobjetossonunaherramienta
fundamentalparalaimplementacindemuchasdelas
asociacionespresentesenundiseo
Empresa 0..1 trabaja en * Persona

empleados
El pseudoatributo empleados de la clase Empresa

introduce la necesidad de una coleccin de personas
ColeccionesdeObjetos(2) ColeccionesdeObjetos(3)
Lascoleccionesdebenpermitir: Desarrollarcadacoleccinenformantegracadavez
Realizariteracionessobresuselementos quesenecesitaresultapocoprctico
Realizarbsquedasdeelementosporclave(encasode
Esposibledefinirunanicavezunainfraestructura
queloselementostenganuna)
comnquesirvadebaseparatodaslascolecciones
Realizarbsquedasdiversas
especficas:
Coleccionesparamtricas(templates):eltipodelelementoa
almacenaresdeclaradocomoparmetroqueserinstanciado
algenerarlacoleccinparticular
Coleccionesgenricas:puedenalmacenardirectamente
cualquiertipodeelemento

ColeccionesGenricas
GenericidaddelaColeccin
ColeccionesGenricas
Unacoleccingenricaestdefinidadeformatalque Cmolograrqueunelementodeunaclasecualquiera
puedaconteneracualquiertipodeelemento puedaseralmacenadoenlacoleccingenrica?
Aspectosaconsiderar: SedefinelainterfazdemarcaICollectible
Cmolograrqueunelementodeunaclasecualquiera Cuandosedeseaqueloselementosdeunaciertaclase
puedaseralmacenadoenlacoleccingenrica? puedanseralmacenadosenunacoleccingenricase
Cmosedefinelacoleccingenrica? solicitaquedichaclaserealicelainterfaz
ICollectible
Deestaformalacoleccingenricacontendr
elementos coleccionables (es decir, que
implementarnlainterfazICollectible)
ColeccionesGenricas
ColeccionesGenricas
GenericidaddelaColeccin(2)
Encapsulamiento
Ejemplo: Cmosedefineunacoleccingenrica?
LaclasePersonadeberealizarlainterfazdemarca Lanocindecoleccinesindependientedesu
ICollectibleparapoderagregarpersonasauna implementacin
coleccingenrica Seseparalaespecificacindelaimplementacin:
SedefineunainterfazICollection
interface Unaciertacoleccingenricaserunaimplementacinque
ICollectible Una interfaz de marca no posee realiceestainterfaz
ninguna operacin, por lo que no
obliga a las clases que la
implementan a presentar ningn
servicio.
Persona

ColeccionesGenricas ColeccionesGenricas
Realizaciones Realizaciones(2)
Podrnexistirdiferentesrealizaciones(cadaunaconsu
Esto es lo que la hace
estructuradedatosparticular)delacoleccingenrica genrica a la coleccin
interface
ICollection
add(ICollectible)
interface remove(ICollectible)
interface
ICollection member(ICollectible)
ICollectible
isEmpty():Boolean
add(ICollectible)()
remove(ICollectible)()
member(ICollectible)()
isEmpty() : Boolean
Persona
Array List DLList BinTree
Array List DLList BinTree
ColeccionesGenricas
RealizacindeunaCol.Genrica
Realizaciones(3)
Estructuradeunacoleccingenrica: LainterfazICollectiondeclaraquserviciosdebe
proveerunacoleccin
: Node : Node : Node Esposiblerealizardichainterfazdediferentesmaneras
mediantediferentesestructurasdedatos
Realizacionesposibles:
: Persona : List
ArrayoVector
Listacomnodoblementeenlazada
p1: Persona p2: Persona p3: Persona Arbolbinario
Etc.
realiza ICollection Vistos como elementos que

realizan ICollectible
RealizacindeunaColeccinGenrica Lista RealizacindeunaColeccinGenrica
Comn ListaComn(2)
Eldiseodeunalistacomnutilizandoclasesnodifiere Lasoperacionesnoseresuelvenenformacompletaenla
significativamentedeldiseousual claseList
1:add(o) 1.1:create(o,first)
:List :Node
next 0..1
0..1
List Node
first 1.1:e:=getElem()
elem 1 1.2a*:[e<>o]e:=getNext()
interface 1:remove(o) 1.2b:[e=o]remove(o)

ICollectible
:List first:Node
Iteradores
Esmuycomnnecesitarrealizariteraciones
sobreloselementosdeunacoleccin
LainterfazICollectionesaumentadacon
lasiguienteoperacin:

getIterator():IIterator
Iteradores
Iteradores(2) Estructura
Uniterador(sugeridoenelpatrndediseo
Iterator)esunobjetoquepermiterecorrerunoa
interface
unoloselementosdeunacoleccin IIterator
next()
Uniteradoresunobservadorexternodela current():ICollectible
hasCurrent():Boolean
coleccin(noenelsentidodelpatrnObserver)
Unacoleccinpuedetenerdiferentesiteradores
realizandodiferentesiteraciones ArrayIterator ListIterator DLListIterator BinTreeIterator
simultneamente
Iteradores Iteradores
UsodeIteradores RealizacindeIteradores
Comoejemploderealizacindeiteradoressepresenta
class Venta {
private: eldiseodeuniteradorsobrelistascomunes
ICollection *lineas;
public: LaclaseListIterator realizalainterfaz
float totalVenta();
virtual ~Venta(); IIterator
};
float Venta::totalVenta() {
float total = 0;
for(IIterator *it = lineas->getIterator(); it->hasCurrent(); it->next()) {

LineaDeVenta *ldv = dynamic_cast<LineaDeVenta *>(it->getCurrent());
total += ldv->subtotal();
}
return total;
}

RealizacindeIteradores(2) RealizacindeIteradores(3)
Estructura: Interacciones:
null si la lista
next 0..1 es vaca
0..1
List Node
first 1: i := getIterator() : IIterator 1.1: i := create(first)
0..1 current elem 1 : List : ListIterator
interface
ListIterator ICollectible
1: next() 1.1: n := getNext()
: ListIterator current : Node
RealizacindeIteradores(4) RealizacindeIteradores(5)
Interacciones(cont.): Ejemplo:

: Node : Node : Node
1: o := current() : ICollectible 1.1: o := getElem()
: ListIterator current : Node : List
: Persona : Persona : Persona
: ListIterator
1: b := hasCurrent()
b := (current <> null)
: ListIterator
realiza IIterator

Diccionarios
Undiccionarioesuntipoparticulardecoleccin
enelcualsealmacenanobjetosquepuedenser
identificadosporunaclave
SedefinelainterfazIDictionaryyseutilizaen
formaanlogaalainterfazICollection:
ExistirndiferentesrealizacionesdeIDictionary
Lasmismascontendrnelementosquerealicenla
interfazICollectible
Diccionarios Diccionarios
UsodeClaves UsodeClaves(2)
Seesttratandolanocindediccionariogenrico
porloquelaclavequeidentificaaloselementos interface
IKey
debesertambingenrica
equals(IKey) : Boolean()
SedefinelainterfazIKey: Esta operacin siempre
castea el parmetro a
Debeserrealizadaporunaclasequerepresentalaclavede clase PersonaKey
loselementosaincluireneldiccionario
PersonaKey Esta clase no tiene
Contienenicamentelaoperacin nombre : String por qu ser la nica
equals(IKey):booleanutilizadaparacompararclaves equals(IKey) : Boolean() clave de Persona
concretas
Los atributos de la clave concreta son una combinacin de atributos de la clase

Diccionarios Diccionarios
DiccionariosGenricos DiccionariosGenricos(2)
Ejemplo:
: PersonaKey : PersonaKey : PersonaKey
interface
: Node : Node : Node
IDictionary
add(IKey,ICollectible)
remove(IKey)
member(IKey):Boolean : List
find(IKey):ICollectible
isEmpty():Boolean
List realiza IDictionary : Persona : Persona : Persona
y ya no ICollection
La relacin entre una persona y su clave es particular a cada diccionario.

La clave que le corresponde a una persona es la referenciada por
el nodo que referencia a la persona (determinada al momento del add()).
Diccionarios
IteracionesenDiccionarios
Undiccionarioesunacoleccinporloquetienesentido
necesitariterarsobresuselementos
SeincorporaalainterfazIDictionary:
getElemIterator():IIteratorquedevuelve
uniteradorsobreloselementoscontenidosenel
diccionario
getKeyIterator():IIteratorquedevuelveun
iteradorsobrelasclavesdeloselementoscontenidosenel
diccionario
Bsquedas Bsquedas(2)
Lasbsquedasporclavenosonelnicotipodebsqueda Dadoqueestetipodebsquedasdependendecada
quesesuelerequerir coleccinnoseimplementanenlascoleccionesgenricas
Existeotrotipodebsquedasquenoinvolucran Deestaformasedefineunaoperacinporcadabsqueda
necesariamenteunaclave: necesaria:
Buscartodoslosempleadosmenoresdeuna Porejemploparabuscarlosempleadoscontratadosantesde
ciertaedad unafecha:
Buscartodoslosempleadoscontratados
antesdeunafechadada
selectContratadosAntes(Fecha):ICollection
Bsquedas(3) Bsquedas(4)
Lasoperacionesdebsquedasonmuysimilares
List * ClaseA::selectContratadosAntes(Fecha f) {
List * result = new List(); entres
ListIterator * it = coleccion->getIterator();
Lasbsquedasentodaslascoleccionesson
while(it.hasCurrent()) { similaressalvo:
if(((Persona*)it.current())->getFecha()<f)
Lacondicinquedeterminalainclusindeunelementoenel
result->add(it.current());
it.next(); resultado
} Losparmetros
return result;
} Eltipodeliteradorylacoleccinresultado
Notar que todas las variantes de select() de ColPersona sern

exactamente iguales entre s a menos de esta porcin del cdigo
Seraposibleincorporaralasinterfaces Cmomanejarlasdiferenciasmencionadasentre
ICollectioneIDictionaryrespectivamente lasdiferentesimplementaciones?
lasoperaciones: EltipodeliteradorseraIIterator
EltipodelresultadoseraICollectiono
select(ICondition) : ICollection
IDictionaryrespectivamente
select(ICondition) : IDictionary Lacondicinencapsula:
LainterfazIConditionsedefinecomo Elolosparmetrosdelabsqueda(ensusatributos)
Elalgoritmoquedeterminasiunelementodelacoleccindebe
interface
ICondition pertenecerademsalresultado
holds(ICollectible):Boolean() (enelmtodoasociadoaholds())
en cada realizacin holds() indicar si un cierto objeto

debe formar parte del resultado del select()
Unaposibleimplementacindeselect()enuna Deestaformalasclasesqueimplementan
realizacindeICollectionsera: IConditionsonestrategiasconcretasqueel
select()utilizaparaconstruirlacoleccin
ICollection * List::select(ICondition * cond) { resultado
ICollection * result = new List();
IIterator * it = coleccion->getIterator();
EnestaaplicacindeStrategysedanlas
siguientescorrespondencias:
while(it->hasCurrent()) { ListContext
if(cond->holds(it->current())) IConditionEstrategia
result->add(it->current());
it->next();
select()solicitud()
} holds()algoritmo()
return result;
}
Bsquedas(9)
Ejemplode
condicin // CondEdad.h
concreta: class CondEdad : ICondition {
private:
int valorEdad;
public:
CondEdad(int i);
bool holds(ICollectible *ic);
class Persona : ICollectible { }
private: // CondEdad.cpp
String nombre; CondEdad::CondEdad(int i) {
int edad; valorEdad = i;
public: }
Persona(); bool CondEdad::holds(ICollectible *ic) {
String getNombre(); Persona * p = (Persona *)ic;
int getEdad(); return (p->getEdad() == valorEdad);
} }
ContenedoresSTL ContenedoresSTL
Usualmenteloslenguajesdeprogramacinofrecen LaSTLproveecontenedores
bibliotecasparaelmanejodecolecciones Loscontenedoressonclasescuyopropsitoson
C++ofrecelaStandardTemplateLibrary,unconjuntode almacenarotrosobjetos
contenedores,iteradoresyotrasutilidadesparamanejar Algunoscontenedores
conjuntosdeobjetos. set<T>:Unacoleccindeobjetos. Permiteopcionalmente
Esunaalternativaaimplementarcoleccionesgenricas ordenamiento
(nosereinventalarueda) map<K,V>:UnDiccionariodeclavesdetipoKyvaloresde
tipoV
Otros:vector,queue,list,stack
Todosloscontendedoressonclasesparamtricas

Set Ejemplo
set<int> col;
Permiteelalmacenamientodeunacoleccinde set<int>::iterator it; // iterador para set<int>
elementos
for (int i=1; i<=5; i++) // inicializa
Permiteordenamiento(pordefectoseusaeloperador<) col.insert(i*10); // col: 10 20 30 40 50
Permiteiterarsobreloselementos it = col.find(20); // busca un elemento
col.erase (it); // borra 20
col.erase (col.find(40)); // borra 40
cout << "col contiene:";

for (it=col.begin(); it!=col.end(); ++it){
int current = *it;
cout << ' ' << current;
}
Iteradores Iteradores(2)
set<Empleado *> col;
Laoperacinbegin() devuelveuniteradoralprincipio Empleado *e1 = new Empleado("pato");
Empleado *e2 = new Empleado("poto");
delacoleccin Empleado *e3 = new Empleado("carlitos");
Empleado *f = new Empleado("peto");
end() devuelveuniteradorunlugardespusdelfinal
delacoleccin.Seutiliza col.insert(e1);
col.insert(e2);
Paramarcarelfinalenlasiteracionesfor() col.insert(e3);
Enlaoperacinfind(e),paraindicarquenoencuentra std::cout << "col contiene";

elelementoe for (set<string>::iterator it=col.begin(); it!=col.end(); ++it){
Empleado *current = *it;
Eltipodeliteradoresset<T>::iterator cout << ' ' << current->getNombre();
}
*it devuelveelelementoactual(detipoT) // imprime carlitos pato poto (usa el orden <)
++it avanzaunlugarenlaiteracin col.find(e1) // devuelve un iterador situado en el elemento pato

col.find(f) // devuelve col.end()
Map<K,V> Map<K,V>(2)
BrindalamismafuncionalidadqueIDictionary map<string, Usuario *> col;
// agrega elementos
Permitebsquedaporclaveeiteraciones. Usuario *u1 = new Usuario("Gustavo Cerati");
Usuario *u2 = new Usuario("Len Gieco");
Opcionalmentesepuedecambiarlaformade
comparacindelasclaves col["cerati"] = u1;
col["gieco"] = u2;
col["gieco"]; // devuelve u2
col["sumo"]; // devuelve NULL
col.erase("gieco"); // borra elementos

col.erase("cerati");
col.empty(); // devuelve true
Iteracinenmap Iteracinenmap(2)
Eliteradordemap<K,V>iterademaneraordenadaenlas map<char,int> dict;
map<char,int>::iterator it;
clavesycadaelementoesdetipoPair<K,V> Imprime
dict['b'] = 100; a => 200
LoselementosseiteranporelordendelaclaveKde b => 100
dict['a'] = 200;
menoramayor dict['c'] = 300; c => 300
for (it= dict.begin(); it!=dict.end(); ++it){
char clave = it->fist;
int valor = it->second;
cout << clave << " => " << valor << '\n';
}

Contenido
Singleton
State
Implementacin
Observer
PatronesdeDiseo
Factory
SingletonEjemplo
Singleton
-instancia : Singleton
-Singleton()
+getInstancia() : Singleton
+operacion()
SingletonCdigo SingletonCdigo(2)
// Singleton.cpp
// Singleton.h #include "Singleton.h"
class Singleton { Singleton * Singleton::instancia = NULL;
private:
static Singleton * instancia; Singleton::Singleton() {...}
Singleton(); Singleton * Singleton::getInstancia() {
public: if (instancia == NULL)
static Singleton * getInstancia(); instancia = new Singleton();
void operacion(); return instancia;
}; }
void Singleton::operacion() {...}
SingletonCdigo(3)
// Ejemplo de uso
#include "Singleton.h"
int main() {
Singleton * ms;
ms = Singleton::getInstancia();
ms -> operacion();
return 0;
}
StateEjemplo StateEjemplo(2)
Puertaautomticacontroladaporuncontrolremotodeun
solobotn:
Control
boton / m.cerrar() Motor
abrir()
cerrar()
Abierto Cerrado
Motor maneja el motor
boton / m.abrir() que abre y cierra la puerta
StateCdigo StateCdigo(2)
// EstadoControl.h
#include "Motor.h" // Abierto.h
class EstadoControl { #include "EstadoControl.h"
public:
class Abierto : public EstadoControl {
virtual void boton(Motor * m, EstadoControl *&e) = 0;
public:
};
void boton(Motor * m, EstadoControl *&e);
};
StateCdigo(3) StateCdigo(4)
// Abierto.cpp
// Control.h
#include "EstadoControl.h"
#include "Motor.h" #include "EstadoControl.h
#include "Abierto.h" #include "Motor.h"
#include "Cerrado.h" class Control {
void Abierto::boton(Motor * m, EstadoControl *&e) { private:
// Cerramos la puerta EstadoControl * estadoActual;
m -> cerrar(); Motor * motor;
public:
// Pasamos al proximo estado Control();
e = new Cerrado(); void apretarBoton();
} };
StateCdigo(5) StateCdigo(6)
#include "Control.h" // Ejemplo de uso
#include "Cerrado.h"
#include "EstadoControl.h" #include "Control.h"
Control::Control() { int main() {

this->estadoActual = new Cerrado();
}
Control * c = new Control();
// Apretamos el boton (deberia ABRIRSE)
void Control::apretarBoton() {
EstadoBoton *viejo = estadoActual;
c->apretarBoton();
// cambia estadoActual // Apretamoe el boton (deberia CERRARSE)
estadoActual->boton(motor, estadoActual);
c->apretarBoton();
if(viejo != estadoActual) return 0;
delete viejo; // borrar viejo estado
} }
StateAlternativas
Cuandoelcontextopasalainformacinnecesaria
alosestados,stosdevuelvenelnuevoestadoy
nodependendelcontexto.
Cuandoelcontextosepasaasmismoalos
estados,stospuedenmodificardirectamenteel
estadoactualdelcontextoyquedan
dependientesdelcontexto.

ObserverEjemplo ObserverEjemplo(2)
Unpuestodeventatienevariosproductosparavender,de
loscualessenecesitacontrolarsustock.Cuandoelstockde PuntoDeVenta
algunodeellosllegueacero,deberavisarsealdepsito * interfaz
+venderProducto(entrada idProd : int, entrada cant : int) IObserver
(paraquesepreparenarecibirlosnuevosproductos)yalos +agregarObservador(entrada o : IObserver) +notify(entrada idProd : int)
+eliminarObservador(entrada o : IObserver)
proveedores(paraqueproveandemsstock). -notificarObservadores(entrada idProd : int)
Deposito Proveedor
+notify(entrada idProd : int) +notify(entrada idProd : int)

ObserverCdigo ObserverCdigo(2)
// PuntoDeVenta.h
// PuntoDeVenta.cpp
#include IObserver.h
void PuntoDeVenta::venderProducto(int idProd,int cant){
class PuntoDeVenta {
if(productos[idProd]->getStock() < cant)
private:
notificarObservadores(idProd);
set<Producto *> productos;
//
set<IObserver *> observers;
}
void notificarObservadores(int idProd);
public:
void PuntoDeVenta::notificarObservadores(int idProd){
void venderProducto(int idProd, int cant);
set<IObserver*>::iterator it;
// Permite registrar un observador nuevo
for(it = observers.begin(); it != observers.end(); ++it)
void agregarObservador(IObserver *o);
it->notify(idProd);
// Permite desregistrar un observador
}
void eliminarObservador(IObserver *o);
};
ObserverCdigo(3) ObserverCdigo(4)
// Deposito.h
// PuntoDeVenta.cpp (cont.) class Deposito : public IObserver {
private:
void PuestoDeVenta::agregarObservador(IObserver *o){ ...
observers->insert(o); public:
} void notify(int idProd);
void PuestoDeVenta::eliminarObservador(IObserver *o){ };
observers->erase(o); // Deposito.cpp
}
void Deposito::notify(int idProd) {
// hacer lugar para recibir
// nuevo stock de 'idProd'
}
ObserverCdigo(5) ObserverCdigo(6)
// Ejemplo de uso
// Proveedor.h
int Main() {
class Proveedor : public IObserver {
PuntoDeVenta * pdv = ...
private:
Deposito * deposito = ...
...
Proveedor * proveedor = ...
public:
void notify(int idProd); // Registramos los observadores
}; pdv -> agregarObservador(deposito);
// Proveedor.cpp pdv -> agregarObservador(proveedor);
void Proveedor::notify(int idProd) { // Vendemos un producto en cantidad

// pedir ms unidades del // suficiente para agotar su stock
// producto 'idProd' pdv -> venderProducto(id, mucho);
} }
ObserverAlternativas
Cuandoelsubjectpasalainformacinnecesariaa
losobservadores(comodatosenlosparmetros
delnotify),stosnodependerndel(comoenel
ejemplo).
Cuandoelsubjectsepasaasimismoalos
observadores(comothisenelnotify),stos
dependerndel.

FactoryEjemplo FactoryEjemplo(2)
FormPrincipal
Setieneunafbricadecontroladores
quepermiteelaccesoastosdesdela
presentacin,sinquestaquede singleton
interfaz Fabrica interfaz
acopladaaloscontroladores(mediante ISistema1
+oper1()
-instancia : Fabrica
+getISistema1() : ISistema1
ISistema2
+oper3()
elusodeinterfacesdelsistema). +oper2() +getISistema2() : ISistema2

+getInstancia() : Fabrica
+oper4()
Controlador1 Controlador2
+oper1() +oper3()
+oper2() +oper4()
FactoryCdigo
FactoryAlternativas // ------------ Alternativa 1 ------------
ISistema1 Fabrica::getISistema1() {
1. QueloscontroladoresseanSingletony return Controlador1.getInstancia();
simplementeseanaccedidosmediante }
getInstance()desdelaFbrica. // ------------ Alternativa 2 ------------
2. QueloscontroladoresnoseanSingletonyquela ISistema1 Fabrica::getISistema1() {
if (this->sistema1 == NULL)
Fbricamantengaunareferenciaacadaunode this->sistema1 = new Controlador1();
elloscontrolandosuunicidad. return this->sistema1;
3. QueloscontroladoresnoseanSingletonyquela }
Fbricanomantengareferencias,sinoque // ------------ Alternativa 3 ------------
devuelvaunanuevainstanciadelcontrolador ISistema1 Fabrica::getISistema1() {
return new Controlador1();
cadavez. }

Diapositivas 2013

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Diapositivas 2013

Hochgeladen von

Copyright:

Verfügbare Formate

ContenidoGral.

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 2

AlgunasActividades Pero Hay Ms

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 5 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 6

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 7 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 8

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 9 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 10

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 11 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 12

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 13 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 14

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 15 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 16

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 17 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 18

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 19 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 20

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 23 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 24

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 25 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 26

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 27 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 28

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 29 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 30

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 31 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 32

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 33 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 34

Programacin4Curso2013 DesarrolloOrientadoaObjetosbasadoenUML 35 Programacin4Curso2013 DesarrolloOrientadoaObjetosbasado enUML 36

: Sistema Object1 Object2

* [mas productos] Message1

realizarPago(monto) Object1 Object2

total con impuestos

Programacin4Curso2013 ConceptosBsicos(1eraparte) 4 Programacin4Curso2013 ConceptosBsicos(1eraparte) 5

Programacin4Curso2013 ConceptosBsicos(1eraparte) 6 Programacin4Curso2013 ConceptosBsicos(1eraparte) 7

Programacin4Curso2013 ConceptosBsicos(1eraparte) 8 Programacin4Curso2013 ConceptosBsicos(1eraparte) 9

Programacin4Curso2013 ConceptosBsicos(1eraparte) 10 Programacin4Curso2013 ConceptosBsicos(1eraparte) 11

Programacin4Curso2013 ConceptosBsicos(1eraparte) 12 Programacin4Curso2013 ConceptosBsicos(1eraparte) 13

Programacin4Curso2013 ConceptosBsicos(1eraparte) 14 Programacin4Curso2013 ConceptosBsicos(1eraparte) 15

Programacin4Curso2013 ConceptosBsicos(1eraparte) 16 Programacin4Curso2013 ConceptosBsicos(1eraparte) 17

Programacin4Curso2013 ConceptosBsicos(1eraparte) 20 Programacin4Curso2013 ConceptosBsicos(1eraparte) 21

Para que sea un datatype, las operaciones no pueden modificar

Programacin4Curso2013 ConceptosBsicos(1eraparte) 24 Programacin4Curso2013 ConceptosBsicos(1eraparte) 25

Programacin4Curso2013 ConceptosBsicos(1eraparte) 28 Programacin4Curso2013 ConceptosBsicos(1eraparte) 29

Programacin4Curso2013 ConceptosBsicos(1eraparte) 30 Programacin4Curso2013 ConceptosBsicos(1eraparte) 31

Programacin4Curso2013 ConceptosBsicos(1eraparte) 34 Programacin4Curso2013 ConceptosBsicos(1eraparte) 35

class Banda: public Artista{

Programacin4Curso2013 ConceptosBsicos(1eraparte) 38 Programacin4Curso2013 ConceptosBsicos(1eraparte) 39

Programacin4Curso2013 ConceptosBsicos(1eraparte) 40 Programacin4Curso2013 ConceptosBsicos(1eraparte) 41

Programacin4Curso2013 ConceptosBsicos(1eraparte) 42 Programacin4Curso2013 ConceptosBsicos(1eraparte) 43

class Solista: public Artista { class A { class B {

Paraunaclasedeterminada,elmtodoasociado class Banda: public Artista { Banda

Programacin4Curso2013 ConceptosBsicos(1eraparte) 46 Programacin4Curso2013 ConceptosBsicos(1eraparte) 47

Programacin4Curso2013 ConceptosBsicos(1eraparte) 48 Programacin4Curso2013 ConceptosBsicos(1eraparte) 49

Programacin4Curso2013 ConceptosBsicos(1eraparte) 50 Programacin4Curso2013 ConceptosBsicos(1eraparte) 51

Programacin4Curso2013 ConceptosBsicos(1eraparte) 52 Programacin4Curso2013 ConceptosBsicos(1eraparte) 53

Programacin4Curso2013 ConceptosBsicos(1eraparte) 60 Programacin4Curso2013 ConceptosBsicos(1eraparte) 61

Programacin4Curso2013 ConceptosBsicos(1eraparte) 66 Programacin4Curso2013 ConceptosBsicos(1eraparte) 67

Programacin4Curso2013 ConceptosBsicos(1eraparte) 68 Programacin4Curso2013 ConceptosBsicos(1eraparte) 69

Programacin4Curso2013 ConceptosBsicos(1eraparte) 70 Programacin4Curso2013 ConceptosBsicos(1eraparte) 71

cout << "El total es" << total; Despacha dinmicamente al

Programacin4Curso2013 ConceptosBsicos(1eraparte) 72 Programacin4Curso2013 ConceptosBsicos(1eraparte) 73

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 3 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 4

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 5 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 6

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 7 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 8

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 9 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 10

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 11 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 12

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 13 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 14

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 17 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 18

Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 21 Programacin4Curso2013 Requerimientos&IntroduccinalAnlisis 22

Nombre Alta de Vuelo

Reserva y Compra de Pasaje

Nombre Reserva y Compra de Pasaje

Operacin consultarVuelo(ae1:string, ae2:string, fecha:Date):

Operacin comprarPasajeTarjeta(numTar:int, pagos:int):float