Donar $20 Donar $50 Donar $100 Donar mensualmente
 


Enviar respuesta 
 
Calificación:
  • 0 votos - 0 Media
  • 1
  • 2
  • 3
  • 4
  • 5
Buscar en el tema
Final diseño de sistemas 28/02/2015 RESUELTO
Autor Mensaje
agusbrand Sin conexión
Profesor del Modulo A

*****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 228
Agradecimientos dados: 113
Agradecimientos: 55 en 19 posts
Registro en: Dec 2010
Mensaje: #1
Final diseño de sistemas 28/02/2015 RESUELTO Finales Diseño de Sistemas
Hola, alguien tiene el final de esta ultima fecha? o se acuerda un poco lo que tomaron... Dejaron los 5/10 min para verlo/irse ?


Muchas gracias!
(Este mensaje fue modificado por última vez en: 24-01-2016 13:09 por CarooLina.)
03-03-2015 23:30
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
rod77 Sin conexión
Presidente del CEIT
:o
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 1.075
Agradecimientos dados: 127
Agradecimientos: 397 en 175 posts
Registro en: Mar 2011
Mensaje: #2
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
Fijate en http://www.dds.com.ar en la parte de repositorio de examenenes que estan. Subieron el del 28 y el del 14 . Y el del 21 esta en un post.
y te daban 10 minutos para ver el ezexamen, y sino te ibas.
04-03-2015 07:52
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] rod77 recibio 1 Gracias por este post
agusbrand (04-03-2015)
Diesel Sin conexión
Campeon del cubo Rubik
5to año loading
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 124
Agradecimientos dados: 90
Agradecimientos: 257 en 23 posts
Registro en: Sep 2012
Mensaje: #3
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
viejo que tal? el del 21 de febrero del 2015 no lo encontre.. en un post de aca? de la pagina de dds.com ? dondeeeeee?
ajaja gracias!

EDIT: lo habia buscado como el orto mio.. aca esta el link por si les pasa http://www.utnianos.com.ar/foro/tema-apo...21-02-2015
(Este mensaje fue modificado por última vez en: 24-07-2015 22:01 por Diesel.)
24-07-2015 21:59
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
cuchodelosdecadentes Sin conexión
Campeon del cubo Rubik
soooomos los piratas ...
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 161
Agradecimientos dados: 59
Agradecimientos: 5 en 5 posts
Registro en: Dec 2011
Mensaje: #4
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
hola a todos,

alguno me puede dar una mano con el del 28/02/2015 ? hice el apartado de DER pero tengo problemas en la parte de objetos.
enunciado

el original usa un strategy. hasta ahí no hay dramas, pero despues dice:
Cita:Se desea que los costos por unidad de tiempo (diaria, semanal, mensual) ya no se especifiquen para cada auto sino para cada categoría. De esta forma, todos los autos de la categoría "económico" cuestan lo mismo. La decisión del tipo de facturación (diaria, mensual o semanal) sigue correspondiendo a cada auto.

lo que no entiendo es lo siguieten: en el diagrama original, un auto tiene muchas categorias. entonces, cual habria que tomar como referencia al momento de calcular el costo ? la primera ? la ultima ?
por ahí lo plantee mal o entendi cualquier cosa.
17-01-2016 14:00
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
CarooLina Sin conexión
Colaborador
❥❥❥❥
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3.616
Agradecimientos dados: 1.188
Agradecimientos: 1.393 en 505 posts
Registro en: Sep 2010
Mensaje: #5
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
hola cuchodelosdecadentes !

No es muy claro como se hace el calculo, asi que como ellos primero hciieron un "calcularcosto(...)". Un mensaje que le llega a auto de alguna manera y no tenes idea como.
Yo supuse que de alguna forma ellos mismos te dicen que fecha quieren, la categoria que le corresponde al auto que queres alquilar y vos solo podrias usar calcularCosto(cat,..) osea de alguna forma le llega ese mensaje a auto, por ahi en el final preguntaría si interesa.

love
21-01-2016 11:46
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
[-] CarooLina recibio 1 Gracias por este post
cuchodelosdecadentes (22-01-2016)
cuchodelosdecadentes Sin conexión
Campeon del cubo Rubik
soooomos los piratas ...
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 161
Agradecimientos dados: 59
Agradecimientos: 5 en 5 posts
Registro en: Dec 2011
Mensaje: #6
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
hola CarooLina


yo tb habia planteado algo asi,




clase Categoria(unitarioDiario: Numero, unitarioSemanal: Numero, unitarioMensual: Numero)
metodo unitarioPorDia
unitarioDiario
fin

metodo unitarioPorSemana
unitarioSemanal
fin

metodo unitarioPorMes
unitarioMensual
fin


clase ModoDiario hereda ModoFacturacion
metodo calcularCosto(categoria: Categoria, desde: Fecha, hasta: Fecha)
(self cantidadDeDias(desde,hasta)) * (categoria unitarioPorDia)
fin

clase ModoSemanal hereda ModoFacturacion
metodo calcularCosto(categoria: Categoria, desde, hasta)
(self cantidadDeSemanas(desde,hasta))*(categoria unitarioPorSemana)
fin


clase ModoMensual hereda ModoFacturacion
metodo calcularCosto(categoria: Categoria, desde, hasta)
(self cantidadDeMeses(desde,hasta))*(categoria unitarioPorMes)
fin

clase Auto(modo: ModoFacturacion)
atributo categorias

metodo perteneceA(categoria)
categoria contiene(categoria)
fin

metodo calcularCosto(categoria, desde, hasta)
if(! self perteneceA(categoria) )
lanzar nueva Excepcion

modo calcularCosto(categoria, desde, hasta)
fin



pero me hace ruido que un auto tenga muchas categorias porque justamente eso te obliga a parametrizar la categoria.

igual para no hablar sobre el aire, mañana lo subo "semi resuelto" así criticamos entre todos los que se quieran sumar.
saludos y gracias !

edit: aclaro que esto que hice me parece feo, pero es lo que veo por el momento.
(Este mensaje fue modificado por última vez en: 22-01-2016 01:29 por cuchodelosdecadentes.)
22-01-2016 01:24
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
CarooLina Sin conexión
Colaborador
❥❥❥❥
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3.616
Agradecimientos dados: 1.188
Agradecimientos: 1.393 en 505 posts
Registro en: Sep 2010
Mensaje: #7
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
A mi hay cosas del dominio que me dan dudas, que si me las responden por ahi haria otra cosa o no podria hacer nada jajaj blush

la idea de que categoria tenga esos tres atributos no me gusta, por que no es flexible. Cada vez que haya un nuevo modo de facturacion vas a tener que ir a toquetear la interfaz de categoria.
Yo directamente pense en Categoria(Descripcion, costo) y a la hora de crear las distiintas pense (por eso te digo que es algo dudoso del dominio)

ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

El auto en categoria, tendria todas esas y le agregas el plus (aunque no lo piden) de que una categoria no pueda ser alquilada de cierta manera. No use herencia por que todo lo que tienen es comun, entonces no valia la pena.

Si hubieras hecho esto por ahi seria mas simple meter tambien un templated method (no es que sea obligatorio pero como esta medio turbio por ahi compensa que se yo) La idea de patrones es ayudar, no perjudicarte.
Por que el costo es el mismo y vos tenes que calcular la cantidad de dias, semanas y meses... que si lo pensas algo en comun tienen? Te digo si vos para todo calculas la cantidad de dias, si lo dividis por (30) tenes los meses (esta ultima division la haces en mensual) y por 7 tenes las semanas. Aca si te das cuenta con un poco de mas laburo, pero para tratar de conseguir mas nota.. podes hacer esto. Como lo haces vos repetis codigo--> es mas simple y se lo puede criticar/favorecer blabla

love
22-01-2016 11:56
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
cuchodelosdecadentes Sin conexión
Campeon del cubo Rubik
soooomos los piratas ...
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 161
Agradecimientos dados: 59
Agradecimientos: 5 en 5 posts
Registro en: Dec 2011
Mensaje: #8
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
CarooLina

tenes razon en lo del metodo template, ni me fije en eso.

estuve viendo todo de nuevo, y me parece que hay un double dispatch, un template method, y un composite a medias en este final.

fijate que dice:
Cita:De esta forma, todos los autos de la categoría "económico" cuestan lo mismo

o sea que hay muchas categorias y hay muchos modos de facturacion. a su vez, cada categoria define el costo unitario para cada modo de facturacion independientemente de cada auto.

entiendo lo que estas haciendo, pero si haces para cada auto:

Cita:ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

me parece que estas definiendo el costo de cada categoria para cada auto.

adjunto lo que tengo hecho hasta ahora.
es para que opines/opinen, no lo planteo como solucion 100%

Punto1:

Spoiler: Mostrar
[Imagen: Drawing4_Copy.png]

Punto2:

Spoiler: Mostrar
[Imagen: Class_Model_Copy.png]

Codigo:

Spoiler: Mostrar



clase Auto
metodo calcularCosto(categoria, desde, hasta)
retornar modo.calcularCosto(categoria, desde, hasta)
fin



clase abstracta Modo

metodo final calcularCosto(categoria, desde, hasta)
/* template method */
retornar self.periodos(desde, hasta) * self.costoUnitario(categoria)
fin

metodo final costoUnitario(categoria)
retornar categoria.unitarioPara(self)
fin

metodo abstracto periodos(desde, hasta)
/* lo implementa cada subclase */
fin


clase ModoSimple hereda Modo

clase ModoDiario hereda ModoSimple
redefinir periodos(desde, hasta)
retornar dias(desde, hasta) /*calcula dias entre dos fechas */
fin

clase ModoSemanal hereda ModoSimple
redefinir periodos(desde, hasta)
retornar semanas(desde, hasta) /* calcula semanas entre dos fechas */
fin

clase ModoEstacional hereda Modo (
atributo condicion: CondicionTemporada
atributo modoDefault: ModoSimple
atributo modoTemporada: ModoSimple

metodo calcularCosto(categoria, desde, hasta)
if(condicion.check(desde,hasta))
retornar modoTemporada.calcularCosto(categoria, desde, hasta)

retornar modoDefault.calcularCosto(categoria, desde, hasta)
fin

interface Categoria
/* define los costos unitarios para cada modo */
/* double dispatch con Modo */
metodo unitarioPara(modo: ModoDiario)
metodo unitarioPara(modo: ModoSemanal)
metodo unitarioPara(modo: ModoMensual)


clase Economico implementa Categoria
/* implementar */

clase NoTanEconomico implementa Categoria
/* implementar */


interface CondicionTemporada
metodo check(desde, hasta)






Notas:

Las desventajas que veo en esto, son las desventajas del double dispatch, ademas de que cada categoria tenga que ser un singleton.
Tambien se puede generalizar mas el composite que esta en el diagrama, pero no se si es necesario.
No veo la necesidad de interfaces entrates/salientes en este final.
(Este mensaje fue modificado por última vez en: 24-01-2016 01:18 por cuchodelosdecadentes.)
23-01-2016 19:01
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
CarooLina Sin conexión
Colaborador
❥❥❥❥
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3.616
Agradecimientos dados: 1.188
Agradecimientos: 1.393 en 505 posts
Registro en: Sep 2010
Mensaje: #9
RE: [PEDIDO] Final diseño de sistemas 28/02/2015
Cita:Estuve viendo todo de nuevo, y me parece que hay un double dispatch, un template method, y un composite a medias en este final.

Double dispatch nunca lo use como patrón ni mencione, se que esta en los apuntes. Por ahi vale la pena preguntarlo =)
Comoposite a medias, me suena muy raro como lo decis.Aunque el gamma menciona algo de un composite con restricciones tendria que volver a leerlo a ver de que trataba.

Cita:me parece que estas definiendo el costo de cada categoria para cada auto.
No! Por que es mas, podes decir que son singleton... (una vez que las creas nadie puede duplicarlas o volver a instanciar) y usas esas mismas para todos los autos.
Pensa que esto, cuando yo lo haga de esta manera va a estar justificado.

SOBRE el punto 1
En modo tenes que tener "id_modo" y el auto debe tener un "id_modo" como fk. Por que un auto tiene un modo (ya que es un strategy) y cada modo puede estar en varios autos. Por eso en auto con id_modo dejas en claro que modo le pertenece a ese auto.
Yo ademas hablaria de "id" mas que codigo, por ahi es solo un nombre.. pero es la costumbre de la cursada, todos hablan de id.
Y por ultimo, una persona se convierte en cliente por que tiene una reserva.. asi que para mi no va con "circulito" no me acuerdo si era cardinalidad o lo otro, va con palito... osea un cliente tiene una o muchas reservas.

Sobre el punto 2
Yo tambien use modo simple y le mande dos flechas desde estacional.
Y lo de las interfaces, que decis, creo que esta bien por que todo es nuesttro

love
24-01-2016 12:45
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
cuchodelosdecadentes Sin conexión
Campeon del cubo Rubik
soooomos los piratas ...
****

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 161
Agradecimientos dados: 59
Agradecimientos: 5 en 5 posts
Registro en: Dec 2011
Mensaje: #10
RE: Final diseño de sistemas 28/02/2015 RESUELTO
CarooLina

Cita:Comoposite a medias, me suena muy raro como lo decis.Aunque el gamma menciona algo de un composite con restricciones tendria que volver a leerlo a ver de que trataba.

claro, ni yo se que quise decir con lo de "a medias". vi que compartian una interface en comun pero como no era estrictamente el composite de libro, puse "a medias". en realidad, el ModoEstacional se compone de dos modos simples y nada mas. hay composicion, pero no es el "patron composite" propiamente dicho ( el de libro). esa seria la forma correcta de justificar. no hay "patron composite".

--------------------------------------

Cita:No! Por que es mas, podes decir que son singleton... (una vez que las creas nadie puede duplicarlas o volver a instanciar) y usas esas mismas para todos los autos.
Pensa que esto, cuando yo lo haga de esta manera va a estar justificado.

entiendo, pero si Categoria es singleton, entonces esto:

Cita:ecoMensual = new Categoria("mensual mas barato", 50)
ecoSemanal = new Categoria("semanal mas barato", 60)
ecoDiario = new Categoria("diario mas barato", 70)

no se podria hacer (justamente porque es singleton).

en java, por ejemplo, harias Categoria.INSTANCE, o Categoria.getInstance(), o cualquier otra implementacion del patron singleton en java. pero siempre habria una sola categoria, es decir, LA categoria. no podrias usar "new" muchas veces con la clase Categoria porque lo primero que harias es marcar el constructor como privado.

en todo caso, tendrias un repositorio de categorias donde vas agregando quitando/agregando objetos/entidades Categoria (identificadas con un string)

pero sigue habiendo un problema:

Cita:Se desea que los costos por unidad de tiempo (diaria, semanal, mensual) ya no se especifiquen para cada auto sino para cada categoría. De esta forma, todos los autos de la categoría "económico" cuestan lo mismo. La decisión del tipo de facturación (diaria, mensual o semanal) sigue correspondiendo a cada auto.

o sea que: a) hay muchas categorias, b) hay muchos modos de facturacion, c) cada auto sigue teniendo su unico modo de facturacion.

entonces cada categoria define el costo unitario por periodo, pero esto obviamente depende del modo de facturacion.
o sea:
la categoria economico define $5/dia para el modo de facturacion diario
la categoria economico define $8/semana para el modo de facturacion semanal
la categoria economico define $20/mes para el modo de facturacion mensual

y de ahi sale el double dispatch(me parece).

poner un atributo costoUnitario en cada categoria (como hice en la primera resolucion que puse), no puede ser una solucion.
eso es, porque en el diagrama original, el modo diario no tiene ningun atributo. o sea seria inventar un atributo. ademas de lo que dijiste vos en ese momento.

-----------------------------------------

aprovecho para preguntarte: alcanzaste a mirar este final ?
(Este mensaje fue modificado por última vez en: 24-01-2016 19:15 por cuchodelosdecadentes.)
24-01-2016 19:07
Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
CarooLina Sin conexión
Colaborador
❥❥❥❥
********

Ing. en Sistemas
Facultad Regional Buenos Aires

Mensajes: 3.616
Agradecimientos dados: 1.188
Agradecimientos: 1.393 en 505 posts
Registro en: Sep 2010
Mensaje: #11
RE: Final diseño de sistemas 28/02/2015 RESUELTO
uh tenes razon en eso del singleton, no lo pense jajaa se me ocurrio mientras te escribia y lo mande jaja.

mm no veo el problema, a mi me gusta lo que te puse en categoria y a menos que tengas una resolucion mejor, me gusta esa =)

love
24-01-2016 22:13
Envíale un email Encuentra todos sus mensajes Agregar agradecimiento Cita este mensaje en tu respuesta
Buscar en el tema
Enviar respuesta 




Usuario(s) navegando en este tema: 1 invitado(s)



    This forum uses Lukasz Tkacz MyBB addons.