diseño de mi practico
Marcelo David Laginestra
Les hago llegar el diseño que estoy haciendo de mi practico para que me lo validen, si tienen ganas y tiempo por supuesto =). mi idea es usar este practico para aprender smalltalk y el tema es que lo mas importante es el diseño por eso no quiero arrancar con el código hasta no estar seguro que esta ok.
Tengo varias dudas que las agregue al final del adjunto.
si hay algo que no queda claro preguntenme y lo aclaro..
Desde ya, Muchas Gracias!!!
saludos.
Marcelo
Marcelo Cortez
Lei tu pdf y me causo mucha sorpresa porque trabaje varios amños en un
sistema de cabinas de peajes para rutas nacioneales y provinciales ,
la verdad no pude dejar de sonreirme con este dominio ademas estaba
hecho en smalltalk. :)
a Ver si te puedo ayudar en algo; en realidad los requerimientos son
mas com<plejos de
los que pusiste , pero claro es un dominio real .
Che uana cosa porque pones los usuarios en la estacion de peaje?
son los transitos que pasan o son los cajeros?
porque los transitos ( los que podriamos llamar usuarios , son
desconocidos por la cabina)
de hecho solo la registracion lo guarda como una categoria ( categoria=tarifa).
Tus preguntas . mis pareceres
• 1) Cómo restringir el sentido de las cabinas.
No lo haces, para q restringilo?
2) Es necesario manejar el monto inicial en la cabina? Yo la cabina la veo como
un sistema que registra los tickets (incluyendo el importe), pero no que maneja
el movimiento de caja.
en realidad en la cabina de peaje y por legislacion la tiqueteadora es
fiscal esto es guarda totales por cierre de caja y emite comprobantes
al respecto ( cierreZ y cierreX)
3) El intervalo maximo y minimo para el informe se debe llevar en variables de
clase?
No entiendo bien esta pregunta .
Si hablamos de informe las variables q indican los intervalos a
generar el reporte no estan en ninguna clase , ( no son relevantes)
porque podes pedir el periodo q quieras.
capaz este no es el caso. vos diras.
4) Como se maneja el perfil del usuario? Yo agregué este atributo pensando en
que indique si es operador o supervisor.
Ahora si entiendo el operador o cajero .puede ser operador o supervisor
yo en realidad lo maneje como un estado del cajero porqe tienen la
misma interfaz ( el supervisor puede operar la via como si fuera
cajero , pero ademas puede hacer muchas otras cosas ( cerrar un turno
, justificar una "discrepancia" sacar reportes fiscales etc,)
la discrepancia es importante porque el sistema real tiene 2 categorizaciones.
1) manual
2) automatica
1) la que ingresa el operador (cajero/supervisor)
2) la que el conjunto de sensores de piso y de la cabina registra
porque sino pensa esto
Me anoto como cajero
le cobro a todos los camiones ( maxima categoria cant de ejes y de
ruedas por eje )
como autos, y me quedo con una diferencia pautada... con el chofer.y
todo tipo de
fraudes ,,,
bueno no me extiendo mas espero te sirva esto.
saludos
MDC
entrada
abajo...
On Nov 23, 12:05 am, "Marcelo Cortez" <smalltalker.marc...@gmail.com>
wrote:
> Hola Marcelo
>
> Lei tu pdf y me causo mucha sorpresa porque trabaje varios amños en un
> sistema de cabinas de peajes para rutas nacioneales y provinciales ,
> la verdad no pude dejar de sonreirme con este dominio ademas estaba
> hecho en smalltalk. :)
>
> a Ver si te puedo ayudar en algo; en realidad los requerimientos son
> mas com<plejos de
> los que pusiste , pero claro es un dominio real .
>
> Che uana cosa porque pones los usuarios en la estacion de peaje?
> son los transitos que pasan o son los cajeros?
> porque los transitos ( los que podriamos llamar usuarios , son
> desconocidos por la cabina)
> de hecho solo la registracion lo guarda como una categoria ( categoria=tarifa).
usuario se refiere al usuario del sistema que se encuentra logueado en
la cabina, y que tambien hay que indicarlo en el ticket, seria el
cajero, pero en el sistema se llama operador (yo quise modelar que hay
dos tipos de usuario del sistema, operador y supervisor)
> Tus preguntas . mis pareceres
>
> · 1) Cómo restringir el sentido de las cabinas.
> No lo haces, para q restringilo?
lo que pasa que en el enunciado dice que cada estacion tiene 5 cabinas
dos sentido ascendente, dos en sentido descendente y una rebatible...
> 2) Es necesario manejar el monto inicial en la cabina? Yo la cabina la veo como
> un sistema que registra los tickets (incluyendo el importe), pero no que maneja
> el movimiento de caja.
>
> en realidad en la cabina de peaje y por legislacion la tiqueteadora es
> fiscal esto es guarda totales por cierre de caja y emite comprobantes
> al respecto ( cierreZ y cierreX)
ok, no sabia eso.
> 3) El intervalo maximo y minimo para el informe se debe llevar en variables de
> clase?
> No entiendo bien esta pregunta .
> Si hablamos de informe las variables q indican los intervalos a
> generar el reporte no estan en ninguna clase , ( no son relevantes)
> porque podes pedir el periodo q quieras.
> capaz este no es el caso. vos diras.
si, tenes razon, yo queria llevarlo en variables, y calculandolo en el
momento, para no tener que calcularlo al final del mes...pero tenes
razon vos.
> 4) Como se maneja el perfil del usuario? Yo agregué este atributo pensando en
> que indique si es operador o supervisor.
>
> Ahora si entiendo el operador o cajero .puede ser operador o supervisor
> yo en realidad lo maneje como un estado del cajero porqe tienen la
> misma interfaz ( el supervisor puede operar la via como si fuera
> cajero , pero ademas puede hacer muchas otras cosas ( cerrar un turno
> , justificar una "discrepancia" sacar reportes fiscales etc,)
>
> la discrepancia es importante porque el sistema real tiene 2 categorizaciones.
> 1) manual
> 2) automatica
> 1) la que ingresa el operador (cajero/supervisor)
> 2) la que el conjunto de sensores de piso y de la cabina registra
> porque sino pensa esto
> Me anoto como cajero
> le cobro a todos los camiones ( maxima categoria cant de ejes y de
> ruedas por eje )
> como autos, y me quedo con una diferencia pautada... con el chofer.y
> todo tipo de
> fraudes ,,,
Este punto me parece interesante, nunca lo pensé así...pensé que los
unicos sensores que habian eran los del telepeaje. =)
Muchas Gracias Marcelo por tus respuestas!!
> bueno no me extiendo mas espero te sirva esto.
> saludos
>
> MDC
>
Marcelo Cortez
> usuario se refiere al usuario del sistema que se encuentra logueado en
> la cabina, y que tambien hay que indicarlo en el ticket, seria el
> cajero, pero en el sistema se llama operador (yo quise modelar que hay
> dos tipos de usuario del sistema, operador y supervisor)
>
Si tenes razon esto a mi, me parecio correcto,( yo tambien lo modele
asi ;) ).
Aca aparece un Objeto una entidad que para nosotros tenia gran
importancia que se llama turno.
el turno si pertenece a un operador.
Creo q el ticket tenia la via y el cajero.
nosotros modelamos el turno como un objeto con estados ( abierto -
cerrado - supervisor )
pensa que pasa si un vehiculo pasa en violacion ( ignorando la barrera
o rompiendola ) el dac genera un transito pero la viaa esta cerrada
esto es un evento de violacion con via cerrada... este es solo un
ejemplo..
porque la via era operada por el supervisor o la "visitaba" el superv.
en gral nuesta via de peaje era una gran maquina de estados
porque hay muchos eventos asincronicos.
y en parte debido a los sensores
Me hago un parrafo para contarte un poco de los sensores q no son pocos
ellos generan algo llamado categoria DAC. ( por categoria automatica)
existen unos sensores en el piso que miden la cantidad de ruedas , la
cantidad de ejes y la cantidad de ruedas dobles con esos datos es
posible categorizar en forma "automatica"
al vehiculo , la categoria manual contra esta genera loque se llama
discrepancia ( diferencia)y se debe mayormente a la falla de sensores
etc...
bueno no me extiendo mas si queres la seguimos por correo privado ,
para no meter ruido en el canal,salvo que opinen lo contrario y
seguimos debatiendo aca. :)
saludos
MDC
Francisco Garau
Marcelo Cortez wrote:
> bueno no me extiendo mas si queres la seguimos por correo privado ,
> para no meter ruido en el canal,salvo que opinen lo contrario y
> seguimos debatiendo aca. :)
> saludos
Yo voto porque sigan aca. Me parece interesante la discusion - es un
caso concreto de disenio entendible por todos.
Saludos,
Pancho
Sergio Fedi
> > para no meter ruido en el canal,salvo que opinen lo contrario y
> > seguimos debatiendo aca. :)
> > saludos
>
> Yo voto porque sigan aca. Me parece interesante la discusion - es un
> caso concreto de disenio entendible por todos.
Me sumo al pedido.
Sigan por aca.
entrada
Gracias Marcelo por responderme! la verdad una suerte encontrar a
alguien que haya trabajado en un sistema de peajes y justo en
Smalltalk! =))
mis notas abajo...
Marcelo Cortez wrote:
> Hola Marcelo
>
> > usuario se refiere al usuario del sistema que se encuentra logueado en
> > la cabina, y que tambien hay que indicarlo en el ticket, seria el
> > cajero, pero en el sistema se llama operador (yo quise modelar que hay
> > dos tipos de usuario del sistema, operador y supervisor)
> >
>
> Si tenes razon esto a mi, me parecio correcto,( yo tambien lo modele
> asi ;) ).
> Aca aparece un Objeto una entidad que para nosotros tenia gran
> importancia que se llama turno.
> el turno si pertenece a un operador.
> Creo q el ticket tenia la via y el cajero.
> nosotros modelamos el turno como un objeto con estados ( abierto -
> cerrado - supervisor )
con respecto a la via, yo lo llevo como cabina y sentido, dado que
dependiendo de la carga de vehiculos algunas cabinas pueden estar en un
sentido o en otro...en el sistema real no importa el sentido en el que
circula el transito por la cabina? o como se maneja en esas cabinas que
cambian el sentido?
con respecto al turno, vos como incorporarías el turno a mi modelo?
(disculpa pero no me lo imagino con la descripcion que vos me
hiciste)..yo en realidad al turno no lo incorporé al sistema porque me
imaginaba lo siguiente:
El operador llega a la empresa y pasa una tarjeta por una lectora
registrando su ingreso, una vez que se retira de la empresa pasa
nuevamente la tarjeta registrando la salida, pero no me lo imagino
registrando su turno de trabajo al loguearse a la cabina, porque no
creo que esté ocho horas en la misma cabina, puede pasar alguna
eventualidad que lo haga de cambiar de cabina o dedicarse a otra tarea
que no sea en la cabina (esto lo digo por desconocimiento del tema).
Por lo tanto me imagine que el manejo de los turnos de trabajo se
manejaba con otro sistema y que no estaba relacionado con el sistema de
administracion de los peajes...
Corregime si estoy equivocado...
> pensa que pasa si un vehiculo pasa en violacion ( ignorando la barrera
> o rompiendola ) el dac genera un transito pero la viaa esta cerrada
> esto es un evento de violacion con via cerrada... este es solo un
> ejemplo..
>
> porque la via era operada por el supervisor o la "visitaba" el superv.
> en gral nuesta via de peaje era una gran maquina de estados
> porque hay muchos eventos asincronicos.
> y en parte debido a los sensores
> Me hago un parrafo para contarte un poco de los sensores q no son pocos
> ellos generan algo llamado categoria DAC. ( por categoria automatica)
>
> existen unos sensores en el piso que miden la cantidad de ruedas , la
> cantidad de ejes y la cantidad de ruedas dobles con esos datos es
> posible categorizar en forma "automatica"
> al vehiculo , la categoria manual contra esta genera loque se llama
> discrepancia ( diferencia)y se debe mayormente a la falla de sensores
> etc...
Esto me parece muy interesante, tantos años pasando por los peajes y
nunca supe de la existencia de estos sensores!
Te cuento que mi sistema solo va a contemplar el ingreso de la
categoria por parte del cajero (confio en que son honestos =) ) sino lo
complicaria mucho y no podría implementarlo....
En tu primer post me decias que el tema de:
>"operador o supervisor
>yo en realidad lo maneje como un estado del cajero porqe tienen la
>misma interfaz ( el supervisor puede operar la via como si fuera
>cajero , pero ademas puede hacer muchas otras cosas ( cerrar un turno
>, justificar una "discrepancia" sacar reportes fiscales etc,) "
Disculpá, pero no entiendo el tema de manejar eso como estado, vos te
referis a que en realidad tenes un cajero y en base a quien se logonee
tenes un atributo que indica si es operador o supervisor?, y de donde
toma esta información para saber el perfil del cajero?
otra cosa, el tema que agregué yo de loguear las actividades de
ingreso y salida del sistema, como lo ves? esta demás? puede servir? o
se hace de otra forma?
Muchas Gracias por tus respuestas!!!!...estoy intentando aprovecharte
dado que tenes conocimiento del dominio, así que cualquier
información con repecto a este sistema que quieras (y puedas)
compartir conmigo será bienvenida!!!
Quizás algunas de mis dudas son básicas pero vengo de varios años de
programación estructurada en visual basic 5/6 y recién este año
estoy entrando en el mundo de la programación orientada a objetos, y
la verdad que se me estan aclarando muchas cosas...
Saludos,
Marcelo
Marcelo Cortez
te contesto entre lineas
> > > usuario se refiere al usuario del sistema que se encuentra logueado en
> > > la cabina, y que tambien hay que indicarlo en el ticket, seria el
> > > cajero, pero en el sistema se llama operador (yo quise modelar que hay
> > > dos tipos de usuario del sistema, operador y supervisor)
> > >
> >
> > Si tenes razon esto a mi, me parecio correcto,( yo tambien lo modele
> > asi ;) ).
> > Aca aparece un Objeto una entidad que para nosotros tenia gran
> > importancia que se llama turno.
> > el turno si pertenece a un operador.
> > Creo q el ticket tenia la via y el cajero.
> > nosotros modelamos el turno como un objeto con estados ( abierto -
> > cerrado - supervisor )
>
> con respecto a la via, yo lo llevo como cabina y sentido, dado que
> dependiendo de la carga de vehiculos algunas cabinas pueden estar en un
> sentido o en otro...en el sistema real no importa el sentido en el que
> circula el transito por la cabina? o como se maneja en esas cabinas que
> cambian el sentido?
Si en realidad en las vias provinciales hay 2 carriles pero suele
suceder q en ocasiones todos transito viene de un solo lado.
Las vias son reversibles. el problema mayor es conectar a los sensores
del lado opuesto al que estaban por lo pronto la via ( el turno tiene
un sentido) ascedente o descendente
>
> con respecto al turno, vos como incorporarías el turno a mi modelo?
> (disculpa pero no me lo imagino con la descripcion que vos me
> hiciste)..yo en realidad al turno no lo incorporé al sistema porque me
> imaginaba lo siguiente:
> El operador llega a la empresa y pasa una tarjeta por una lectora
> registrando su ingreso, una vez que se retira de la empresa pasa
> nuevamente la tarjeta registrando la salida, pero no me lo imagino
> registrando su turno de trabajo al loguearse a la cabina, porque no
> creo que esté ocho horas en la misma cabina, puede pasar alguna
> eventualidad que lo haga de cambiar de cabina o dedicarse a otra tarea
> que no sea en la cabina (esto lo digo por desconocimiento del tema).
> Por lo tanto me imagine que el manejo de los turnos de trabajo se
> manejaba con otro sistema y que no estaba relacionado con el sistema de
> administracion de los peajes...
> Corregime si estoy equivocado...
No , no te equivocas , la via tiene un estado , el evento de tarjeta
si esta cerrado lo pasa a abierto y viceversa.
abierto y cerrado es un togle con la tarjeta de operador .
El turno es justamente la registracion ( los tikets) entre una
apertura y cierre., porque es importante, en primer lugar por hacer
responsable a alguien de los eventos ,
a haber . policia . ambulancia , poder ejecutivo etc son transitos
exentos ) no pagan
violaciones ,con via cerrada o abierta ( turno abierto o cerrado)
discrepancias etc.
Aprovecho para contarte algo mas del dominio, los vehiculos pueden
llegar a pasar a mas de 20 kms por hora mas con telepeaje,.
el sistema maneja muchisimas formas de pago.
en nuestro caso
efectivo
boleto magnetico
tarjeta de proximidad
ademas los pagos tienen subsidios ( que se reportan al organo recaudador)
son con codigos de barras
a eso sumale los DAC ( que te informa del evento del lazo) lazo
magnetico o loop que te informa q un vehiculos salio ( genera el
evento bajar la barrera ( re importante porque sino se chupan o pasan
a granel ))
nosotros modelamos todos los protocolos en smalltalk
no son pocos ademas del registrador fiscal
en Otro capitulo te cuento la division del sistema en 2 partes como
vos señalaste.
la via y la el corrdinador ( un mimico en tiempo real del estado de
todas la vias ) unb poco de distribucion de objetos..
salu2
MDC
el tema es largo , sigamos intercambiando ideas . ..;)
Gustavo Ibarra
> con respecto al turno, vos como incorporarías el turno a mi modelo?
Creo que el turno es un Turno. unTurno puede ser usado por varios
operadores y losTurnos no todos tienen la mismas caracteristicas. Por
ejemplo, no es lo mismo unTurnoNocturno que unTurnoDiurno. Eso
dependiendo del modelo.
> El operador llega a la empresa y pasa una tarjeta por una lectora
> registrando su ingreso, una vez que se retira de la empresa pasa
> nuevamente la tarjeta registrando la salida,
Eso esta bien, para controlar los ingresos y egresos de cada empleado
a la empresa, no lo veo como el Turno en una cabina de peaje. Si es
util para el control de asistencia , llegadas tarde, ausencias,....etc
de los empleados a la empresa. Por lo que entendi,no seria el alcance
de tu sistema.
>pero no me lo imagino
>registrando su turno de trabajo al loguearse a la cabina,
es ahi donde usa el Turno correspondiente. Despues de habilitar la
caja de la cabina con su usuario, sabe que turno le corresponde.
> porque no
> creo que esté ocho horas en la misma cabina, puede pasar alguna
> eventualidad que lo haga de cambiar de cabina o dedicarse a otra tarea
> que no sea en la cabina (esto lo digo por desconocimiento del tema).
Claro como ir al baño, comer, cualquier otra necesidad.
> Por lo tanto me imagine que el manejo de los turnos de trabajo se
> manejaba con otro sistema y que no estaba relacionado con el sistema de
> administracion de los peajes...
No te estas confundiendo control de horarios laborales (ingresos,
egresos,...) con losTurnos de las cabinas que estan en uso ?
Un mismo turno puede ser usado por una misma cabina y la cabina puede
ser operada en el mismo turno por mas de un operador. Un ejemplo: En
la cabina 1, el operario A, quiere ir al baño, entonces el Operario B
lo remplaa. EL operario A y el operario B, operaron la misma cabina de
peaje durante un mismo turno, pero en distinto horario. Los dos
operarios fueron responsable de la cabina 1 en el mismo Turno.
Todo esto si tomas los turnos por rango horarios.
> Corregime si estoy equivocado...
Espero no aportar ruido.
GallegO
Aparte de lo que están discutiendo entre todos hay un detalle que vi con
el tema de fecha/hora, dá la impresión de que tenes pensada una instVar
para fecha y otra para la hora. En Smalltalk tenemos el objeto TimeStamp
que maneja las dos magnitudes al mismo tiempo.
Ej
TimeStamp current. "Devuelve la fecha y hora actuales"
TimeStamp
date: (Date fromString: '01/01/2006')
time: (Time fromString: '12:00'). "Devuelve el primero de enero de
2006 a las 12 del mediodía"
en vez de fecha y hora por separado deberías tener fechaYHora como
instVar o simplemente fecha con la convención de que en fecha siempre
tenes un TimeStamp.
Saludos
GallegO
Marcelo David Laginestra escribió:
Francisco Garau
> el tema de fecha/hora, dá la impresión de que tenes pensada una instVar
> para fecha y otra para la hora. En Smalltalk tenemos el objeto TimeStamp
> que maneja las dos magnitudes al mismo tiempo.
> Ej
> TimeStamp current. "Devuelve la fecha y hora actuales"
> TimeStamp
> date: (Date fromString: '01/01/2006')
> time: (Time fromString: '12:00'). "Devuelve el primero de enero de
> 2006 a las 12 del mediodía"
>
> en vez de fecha y hora por separado deberías tener fechaYHora como
> instVar o simplemente fecha con la convención de que en fecha siempre
> tenes un TimeStamp.
Y siguiendo la misma linea, en la Tarifa tenes fechaDesde y fechaHasta.
Seria mejor modelarlo con un Periodo.
Tarifa ( codigo descCategoria vigencia estacion)
Periodo (inicio fin) - donde incio y fin son Dates o TimeStamps
Escribiendo esto y releyendo el enunciando, me pregunto por que
necesitas el codigo de la tarifa o la descripcion de la categoria...
Por lo que entendi del enunciado, me inclino mas por lo siguiente:
Tarifa ( estacion categoria vigencia precio )
Categoria ( descripcion ) - eg aCategoria ('camion'),
aCategoria('vehiculo particular'), etc.
Saludos,
Pancho
entrada
estoy agregando tus comentarios al modelo, después lo envio para que
me digas si entendí bien.
gracias!
Saludos,
Marcelo
entrada
Gracias GallegO!!!
Ya lo corregí...
Saludos,
Marcelo
entrada
Estoy agregando el Turno al modelo, despues cuando lo mande de nuevo,
si podés mirálo, porque sinceramente no me termina de quedar del todo
claro, pero es por un problema mío de comprension del dominio.
Mis comentarios abajo...
Gustavo Ibarra wrote:
> Hola, perdon que me meta.
>
> > con respecto al turno, vos como incorporarías el turno a mi modelo?
>
> Creo que el turno es un Turno. unTurno puede ser usado por varios
> operadores y losTurnos no todos tienen la mismas caracteristicas. Por
> ejemplo, no es lo mismo unTurnoNocturno que unTurnoDiurno. Eso
> dependiendo del modelo.
Agregué el turno, y le puse una OrderedCollection de operadores, hasta
ahí bien, tambien incorporé las subclases TurnoNocturno y TurnoDiurno
pero no supe que diferencia tienen...asi que las tendría que sacar en
mi modelo o incorporarle alguna responsabilidad que las diferencie...
> > El operador llega a la empresa y pasa una tarjeta por una lectora
> > registrando su ingreso, una vez que se retira de la empresa pasa
> > nuevamente la tarjeta registrando la salida,
>
> Eso esta bien, para controlar los ingresos y egresos de cada empleado
> a la empresa, no lo veo como el Turno en una cabina de peaje. Si es
> util para el control de asistencia , llegadas tarde, ausencias,....etc
> de los empleados a la empresa. Por lo que entendi,no seria el alcance
> de tu sistema.
Tenés razón, esto esta fuera del alcance...
>
> >pero no me lo imagino
> >registrando su turno de trabajo al loguearse a la cabina,
>
> es ahi donde usa el Turno correspondiente. Despues de habilitar la
> caja de la cabina con su usuario, sabe que turno le corresponde.
bueno, esto intenté modelarlo incorporando una OrderedCollection de
turnos en la cabina, además el turno sabe cuanto es la cajaInicial que
ingresa el operador al comenzar el turno...despues lo vas a ver en el
modelo...no se si lo hice bien
> > porque no
> > creo que esté ocho horas en la misma cabina, puede pasar alguna
> > eventualidad que lo haga de cambiar de cabina o dedicarse a otra tarea
> > que no sea en la cabina (esto lo digo por desconocimiento del tema).
>
> Claro como ir al baño, comer, cualquier otra necesidad.
>
> > Por lo tanto me imagine que el manejo de los turnos de trabajo se
> > manejaba con otro sistema y que no estaba relacionado con el sistema de
> > administracion de los peajes...
>
> No te estas confundiendo control de horarios laborales (ingresos,
> egresos,...) con losTurnos de las cabinas que estan en uso ?
Si, tenes razon...
> Un mismo turno puede ser usado por una misma cabina y la cabina puede
> ser operada en el mismo turno por mas de un operador. Un ejemplo: En
> la cabina 1, el operario A, quiere ir al baño, entonces el Operario B
> lo remplaa. EL operario A y el operario B, operaron la misma cabina de
> peaje durante un mismo turno, pero en distinto horario. Los dos
> operarios fueron responsable de la cabina 1 en el mismo Turno.
>
> Todo esto si tomas los turnos por rango horarios.
creo que me faltaria definir los rangos horarios... esto serviría para
sacar por ejemplo los promedios según la banda horaria, pero no sé
como representarlo en el modelo
Gracias nuevamente!!
saludos,
Marcelo
entrada
mis comentarios abajo...
Marcelo Cortez wrote:
> Hola Marcelo
>
> te contesto entre lineas
>
>
> > > > usuario se refiere al usuario del sistema que se encuentra logueado en
> > > > la cabina, y que tambien hay que indicarlo en el ticket, seria el
> > > > cajero, pero en el sistema se llama operador (yo quise modelar que hay
> > > > dos tipos de usuario del sistema, operador y supervisor)
> > > >
> > >
> > > Si tenes razon esto a mi, me parecio correcto,( yo tambien lo modele
> > > asi ;) ).
> > > Aca aparece un Objeto una entidad que para nosotros tenia gran
> > > importancia que se llama turno.
> > > el turno si pertenece a un operador.
Para modelar esto, agregué al empleado, una OrderedCollection de
turnos.
> > > Creo q el ticket tenia la via y el cajero.
> > > nosotros modelamos el turno como un objeto con estados ( abierto -
> > > cerrado - supervisor )
Esto no supe como representarlo en el turno....seguramente lo estoy
pensando mal, pero el turno me lo imagino como que existe o no existe,
me cuesta verlo como que el turno esta abierto o cerrado...además no
comprendo el estado supervisor...si me podes desasnar un poco más te
lo voy a agradecer!! =)
> > con respecto a la via, yo lo llevo como cabina y sentido, dado que
> > dependiendo de la carga de vehiculos algunas cabinas pueden estar en un
> > sentido o en otro...en el sistema real no importa el sentido en el que
> > circula el transito por la cabina? o como se maneja en esas cabinas que
> > cambian el sentido?
>
> Si en realidad en las vias provinciales hay 2 carriles pero suele
> suceder q en ocasiones todos transito viene de un solo lado.
> Las vias son reversibles. el problema mayor es conectar a los sensores
> del lado opuesto al que estaban por lo pronto la via ( el turno tiene
> un sentido) ascedente o descendente
Con este punto lo que hice es sacar la instVar sentido de la Cabina y
ponerla en Turno...
con respecto al tema de los sensores, no lo voy a tener en cuenta para
mi dominio, debido a que tengo que llegar a un programa funcionando y
no lo voy a poder simular...pero es muy interesante el
funcionamiento...
Bien, de acá tengo un estado (instVar) en la cabina, una
OrderedCollection de tickets en el Turno, con respecto a los exentos,
deberia agregar una categoria en la tarifa no? para poder levantar la
barrera...
y con respecto a las violaciones y discrepancias, al no tener en cuenta
los sensores, creo que no entrarian en mi dominio, por lo menos para
este practico...aunque me gustaria agregarlos no puedo...pero
igualmente me interesa que me sigas contando al respecto si hay mas
para contar...o si ves algo de esto que lo pueda tener en cuenta en la
aplicación.
> Aprovecho para contarte algo mas del dominio, los vehiculos pueden
> llegar a pasar a mas de 20 kms por hora mas con telepeaje,.
> el sistema maneja muchisimas formas de pago.
> en nuestro caso
>
> efectivo
> boleto magnetico
> tarjeta de proximidad
Con respecto al pago, voy a contemplar solo efectivo...
> ademas los pagos tienen subsidios ( que se reportan al organo recaudador)
> son con codigos de barras
Esto lo tengo como un diccionario subsidio en la aplicación donde para
un código tengo un porcentaje de descuento a aplicar.
> a eso sumale los DAC ( que te informa del evento del lazo) lazo
> magnetico o loop que te informa q un vehiculos salio ( genera el
> evento bajar la barrera ( re importante porque sino se chupan o pasan
> a granel ))
> nosotros modelamos todos los protocolos en smalltalk
> no son pocos ademas del registrador fiscal
La parte del registrador fiscal me cuesta porque nunca trabajé con
uno...no sé si para esto necesito incorporar algo mas al modelo que
voy a enviar proximamente...
> en Otro capitulo te cuento la division del sistema en 2 partes como
> vos señalaste.
> la via y la el corrdinador ( un mimico en tiempo real del estado de
> todas la vias ) unb poco de distribucion de objetos..
Dale!!!, me interesa mucho esa parte...
Muchas Gracias!!!
entrada
Las 3 de la matina y no puedo dormir por culpa de este práctico =)...
vá igualmente soy de dormir poco...
Acabo de subir en la sección de archivos el modelo de clases que
generé en base a todos los comentarios...se llama
ModeloDeClasesSGPv3.bmp. Si no es el lugar correcto para ponerlo
avisenmé, no encontré la forma de enviar un adjunto a este mensaje
accediendo al grupo via web...
Tengo que releer todos los comentarios y armar un listados de
dudas...porque tengo algunas por ahí dando vueltas todavia...
Desde ya, Muchas Gracias a Todos por la ayuda!!!
Cualquier comentario adicional / modificación / correccion es
bienvenido...
Algo que me viene ahora a la mente es:
En algunas clases como ser cabina tengo código de cabina, y por los
comentarios de Francisco Garau saqué el código de la tarifa...esta
bien que siga teniendo código como atributo en algunas clases? como se
representa esto? yo lo veo como el campo de búsqueda, o la forma de
recorrer la OrderedCollection, pero quizá me esté equivocando porque
tengo muchos años de modelo relacional....
y otra cosa...
Me hago un poco de lío con las OrderedCollection para llevar la info
en varias clases, por ejemplo, turnos lo tengo en tres clases, tickets
tambien...está bien esto? o en algunos lados lo podría evitar?
Bueno Gracias Nuevamente!
Saludos,
Marcelo
GallegO
> Las 3 de la matina y no puedo dormir por culpa de este práctico =)...
> vá igualmente soy de dormir poco...
Estas al horno. ¿Cómo se hace para evitar eso?
> Acabo de subir en la sección de archivos el modelo de clases que
> generé en base a todos los comentarios...se llama
> ModeloDeClasesSGPv3.bmp. Si no es el lugar correcto para ponerlo
> avisenmé, no encontré la forma de enviar un adjunto a este mensaje
> accediendo al grupo via web...
Creo que si es el lugar correcto
[snip]
> representa esto? yo lo veo como el campo de búsqueda, o la forma de
> recorrer la OrderedCollection, pero quizá me esté equivocando porque
> tengo muchos años de modelo relacional....
No revise mucho lo que te dijo Pancho pero conociendo los profesores de
la facultad de Moron te advierto que te saques un poco de la cabeza lo
que te enseñan sobre el #detect: . En smalltalk los objetos "se
conocen" entre si sin necesidad de IDs ni campos claves ni nada de eso.
Asi que los casos puntuales que tengas dudas pregunta, porque es muy
importante que te habitues a esto para que no hagas un desastre ;)
> y otra cosa...
> Me hago un poco de lío con las OrderedCollection para llevar la info
> en varias clases, por ejemplo, turnos lo tengo en tres clases, tickets
> tambien...está bien esto? o en algunos lados lo podría evitar?
Es un tema de mantenimiento de esas OrderedCollection.
Voy a permitirme usar la palabra calcular como sinónimo de seleccionar
(#select:)
Cuanto mas objetoso es el sistema y mas navegabilidad le dá uno
tienden a aparecer mayor cantidad de colecciones.
En los sistemas muy chiquitos se puede tratar de evitar la
proliferacion de colecciones mediante el uso de operaciones sobre
colecciones (#select: #collect: #detect: , etc) y a eso es con lo que
me refiero a calcular. Es decir toda coleccion que pueda ser calculable
o inferida de otra forma no la pongo. Ejemplo puntual sobre tu modelo:
SistemaGestionPeajes tiene turnos (oc)
Cabina tiene turnos (oc)
Empleado tiene turnos (oc)
Turno conoce a la Cabina y tiene una OC de Empleados
Entonces podriamos reemplazar la instVar de coleccion de turnos en la
clase Cabina por el siguiente codigo:
Cabina>>turnos
turnos
"Devuelve una colección con los turnos del receptor."
^SistemaGestionPeajes current turnosDeCabina: self
SistemaGestionPeajes>>turnosDeCabina:
turnosDeCabina: unaCabina
"Devuelve los turnos del receptor cuya Cabina corresponde al
argumento unaCabina."
^self turnos select: [:each | each cabina = unaCabina]
En el caso de empleado seria :
Empleado>>turnos
turnos
"Devuelve una colección con los turnos del receptor."
^SistemaGestionPeajes current turnosDeEmpleado: self
SistemaGestionPeajes>>turnosDeEmpleado:
turnosDeEmpleado: unEmpleado
"Devuelve los turnos del receptor cuyos empleados incluyen al
argumento unEmpleado."
^self turnos select: [:each | each empleados includes: unEmpleado]
Comentarios:
1- Esta es una forma de hacerlo, es práctica para sistemas chicos pero
para otros más grandes podes tener problemas de performance y ademas a
veces un gasto de energia (ciclos valiosos de procesador) cuando en
realidad no era necesario. Tampoco sé si la logica es correcta,
fijate, solo quise darte un ejemplo.
2- Hay muchas formas de implementar que permitirian hacer el
mantenimiento de las colecciones automaticamente pero son quizas mucho
más complicadas y vos necesitas hacer el final :)
3- Quizas lo mas importante, fijate que el codigo es casi identico en
ambos casos, seguro se puede mejorar, es tu tarea.
4- El inconveniente de esta solución es que te quedan muchas
referencias a la global, eso quizas te haga pensar en cambiar el
modelo, que sea navegable de otra manera, pero la verdad, tendria que
ponerme a hacerlo para darme cuenta donde estan los problemas. Me
cuesta pensar sin poner las manos en el teclado, es vicio de
Smalltalker ;)
Cualquier duda...
Saludos
GallegO
entrada
GallegO wrote:
> On 25 nov, 03:10, "entrada" <entr...@gmail.com> wrote:
> > Las 3 de la matina y no puedo dormir por culpa de este práctico =)...
> > vá igualmente soy de dormir poco...
>
> Estas al horno. ¿Cómo se hace para evitar eso?
No, con esto creo que ya no tengo solución...
> > Acabo de subir en la sección de archivos el modelo de clases que
> > generé en base a todos los comentarios...se llama
> > ModeloDeClasesSGPv3.bmp. Si no es el lugar correcto para ponerlo
> > avisenmé, no encontré la forma de enviar un adjunto a este mensaje
> > accediendo al grupo via web...
>
> Creo que si es el lugar correcto
>
> [snip]
> > representa esto? yo lo veo como el campo de búsqueda, o la forma de
> > recorrer la OrderedCollection, pero quizá me esté equivocando porque
> > tengo muchos años de modelo relacional....
>
> No revise mucho lo que te dijo Pancho pero conociendo los profesores de
> la facultad de Moron te advierto que te saques un poco de la cabeza lo
> que te enseñan sobre el #detect: . En smalltalk los objetos "se
> conocen" entre si sin necesidad de IDs ni campos claves ni nada de eso.
> Asi que los casos puntuales que tengas dudas pregunta, porque es muy
> importante que te habitues a esto para que no hagas un desastre ;)
Acá me mataste!, yo pensé que ya estaba entendiendo la programación
orientada a objetos y ahora siento que no se nada! Donde puedo leer un
poco más sobre esto?
Esto lo entiendo, el tema es, tu ejemplo lo veo claro cuando ya tengo
unEmpleado, pero como lo encuentro a ese empleado? es decir, suponete
que tengo la clase empleado(numLegajo, nombre, domicilio, etc)
Yo quiero buscar a un empleado en base a un dato ingresado por el
usuario, en ese caso, yo le digo al usuario de mi sistema, por ej.:
num:= (Prompter prompt:'ingrese numero de legajo' default:'0')
asInteger.
unEmpleado:= empleados detect(:x| x darNumLegajo = num) ifNone(nil).
y ahí sí puedo pedirle los turnos...
Asi lo ví yo en la facultad, sino que otra forma hay de encontrar a
unEmpleado?
Desde ya, Muchas Gracias!
Saludos,
Marcelo
Marcelo Cortez
> Acá me mataste!, yo pensé que ya estaba entendiendo la programación
> orientada a objetos y ahora siento que no se nada! Donde puedo leer un
> poco más sobre esto?
Los sistemas tradicionales y mas lo Orientados a Datos necesitan un
Id porque el "·objeto" sel desarma ( en tablas :) ).
Por eso para volver a armarse necesitan un id en smalltalk esto no
ocurre porque no se desarman los objetos , no en el hambiente.
Por lo gral . en un sistemas de Objetos ( para no usar el termino orientado)
No te hace falta buscar , no todo el tiempo. porque lo mas probable
que esos objetos sean los que esten enviando o recibiendo mensajes.
Quiero decir con esto que la relacion entre ellos es mas organica y en
gral de alguna manera en la resolucion de un metodo el que recibe el
mensaje ya recibe o conoce lo que va a necesitar ( * colaboradores
externos o internos ), no siempre deberia ir a buscarlo, no todo el
tiempo.
Esto tal vez me suena mas a base de datos o programacion tradicional.
saludos
MDC
* colaboradores internos ( variable de instancia)
colaboradores externos ( parametros que pasan con los mensajes )
Es mejor hablar de colaboradores y no de variables y parametros, para
ir diferenciando y pensar distinto de la programacion standard.
Pensa que que todos son objetos , y que lo unico que conoce, el objeto
que tiene colaboradores ya sea interno o externo, es el nombre; el
nombre con lo cual le puede mandar mensajes, incluso para invocarlo.
te ilustro esto con un ejemplo de colaboracion.
Turno>>usuario " la clase turno el mensaje usuario"
^ self usuario
"Explicacion:
el turno usa el "nombre" "usuario" para alcanzar el objeto que
esta detras de este "nombre" ; preferentemente un usuario ( podria
no haber nada o sea nil ) "
entrada
Marcelo Cortez ha escrito:
Hola Marcelo, muy clara tu explicación!!!
Muchas Gracias!
Te cuento que encontré un par de sistemas de peaje:
http://www.telectronica.com/Peaje/nivel%201.htm
http://www.dynagroup.com.ar/Sistemas.htm
Que me sirvieron para imaginarme un poco más como funciona la
cosa...como ser el tema de los lazos, los turnos, las pantallas...vos
podrás pasarme algo mas de info con respecto al sistema con el que
trabajaste?
Queria pedirte si podrás mirar el modelo que dejé en archivos para
ver que te parece...arriba habia enviado algunas dudas que tenia al
respecto como el tema de los turnos...y queria ver que diferencia
encontras con respecto al sistema que vos comentas.
(...tengo que juntar todos los comentarios que me hicieron para ver las
dudas que quedaron colgadas...)
Desde ya, muchas gracias!..
saludos,
Marcelo
Marcelo Cortez
Como accedo a archivos?
Te cuento un poco.,
< nota de color>
El sistema original de peaje lo empezo la empresa techint en la cual
en aquella epoca trabaje en el soft
lugo techin vendio esa division a telectronica , ( en esa empresa no
trabaje ,decline hacerlo ante una oferta de ellos) la empresa que
volvi a trabajar e hice el proyecto en pc ( porque haste ese momento
el controlador era hardware dedicado) es un desprendimiento de
telectronica.
< /nota de color>
salud2
MDC
entrada
Marcelo Cortez ha escrito:
> Hola Marcelo
>
> Como accedo a archivos?
>
> Te cuento un poco.,
> < nota de color>
> El sistema original de peaje lo empezo la empresa techint en la cual
> en aquella epoca trabaje en el soft
> lugo techin vendio esa division a telectronica , ( en esa empresa no
> trabaje ,decline hacerlo ante una oferta de ellos) la empresa que
> volvi a trabajar e hice el proyecto en pc ( porque haste ese momento
> el controlador era hardware dedicado) es un desprendimiento de
> telectronica.
> < /nota de color>
> salud2
> MDC
>
De telectronica es uno de los links que mandé...me recorrí todo el
google buscando algun sistema de peajes echo en smalltalk y no
encontré...vá aunque sea buscaba un diseño para sacar más
datos...pero todavía tampoco encontré..voy a tener que hacer un poco
mas de busquedas en ingles...
Te cuento, para entrar a archivos:
vas a este link:
http://groups-beta.google.com/group/clubSmalltalk?hl=es
que es el que aparece arriba en el grupo para probar la versión beta
de google groups...
de ahí al final de la hoja te muestra los nuevos archivos, y sino a la
derecha de la pantalla aparece una opcion que dice "Archivos" y
clickeando ahí te muestra todos.
Nuevamente gracias por tu ayuda!
Saludos,
Marcelo
GallegO
[...]
> Esto lo entiendo, el tema es, tu ejemplo lo veo claro cuando ya tengo
> unEmpleado, pero como lo encuentro a ese empleado? es decir, suponete
> que tengo la clase empleado(numLegajo, nombre, domicilio, etc)
> Yo quiero buscar a un empleado en base a un dato ingresado por el
> usuario, en ese caso, yo le digo al usuario de mi sistema, por ej.:
>
> num:= (Prompter prompt:'ingrese numero de legajo' default:'0')
> asInteger.
> unEmpleado:= empleados detect(:x| x darNumLegajo = num) ifNone(nil).
>
> y ahí sí puedo pedirle los turnos...
> Asi lo ví yo en la facultad, sino que otra forma hay de encontrar a
> unEmpleado?
Lo que pasa que vos en la facultad viste prácticamente solo scripts.
Si el empleado ya existe para qué buscarlo? Seguramente tengas una lista
con los empleados en alguna parte de tu sistema y puedas elegirlo
directamente de ahi, por lo que no necesitas buscarlo. Las listas
(LitView) cargan objetos* y luego podes enviarle #turnos al objeto
seleccionado. Cuando armes tus View vas a enganchar algunos eventos que
van a darle un poco de automatismo a esto. No lo vas a ver mas como si
fuera un script.
La verdad que es un salto un poco grande pasar de lo que te enseñan
durante la cursada a hacer el final, es raro que tan poca gente pregunte
por aca, se deben copiar mucho jaja.
Si vos tenes tantos empleados que no los queres mostrar en una lista y
queres poner un combo con un boton de buscar ahi sí tendrias que usar un
#detect: o similar pero quizas combinandolo con algun objeto que te
permita buscar usando patterns (* ? Regular expressions, etc).
Tambien algo similar si tenes que validar que no exista un empleado con
el mismo numero de documento cuando agregas uno nuevo, pero en general
es un uso de "busqueda".
*Cuando digo que vos tenes los objetos en tus ListView en PARTS esto no
es tan asi. En PARTS hasta donde recuerdo solo podias tener Strings asi
que nosotros lo habiamos mapeado a un diccionario (si estoy equivocado
corriganme ya que no recuerdo si era en todos los casos). Algo similar
haciamos con las opciones de los DropDown que luego eran ejecutadas via
#perform:
Si queres saber mas sobre alguna de las tecnicas no dudes en
preguntarlo. Esto que te comento es exclusivo de PARTS y no es asi con
lo que habitualmente usamos en VS que es WindowBuilder.
Saludos
GallegO
Gustavo Ibarra
Siempre es mejor dejar todo lo que uno sabe del por que y para que,
que poner cosas por que pareciera que es asi. Apunto mas que nada a
TurnoDiurno y TurnoNocturno, lo comente a modo de ejemplo, como que el
Turno (de operera una pos-pc de una cabina) pareciera existir. Ahora
si va o no en tu modelo, depende de tu cliente (el profesor).No te
compliques, si ves que no te cierra, preferible que no este (o tratar
de resolverlo de otra manera, despues podes refactoriar), por lo menos
asi pienso yo.
Por como pinta que va quedando, te tiene que ir bien, estas apuntando
mas de lo que se pide en la facultad, buen trabajo. despues contanos
que se siente que te pongan un 10 :)
Saludos
--
Saludos,
Gustavo.-
entrada
Gustavo Ibarra ha escrito:
> Hola, espero que no sea tarde estas lineas.
Nunca es tarde cuando la dicha es buena...(además la fecha de
presentación del trabajo es en Marzo =) ) .
> Siempre es mejor dejar todo lo que uno sabe del por que y para que,
> que poner cosas por que pareciera que es asi. Apunto mas que nada a
> TurnoDiurno y TurnoNocturno, lo comente a modo de ejemplo, como que el
> Turno (de operera una pos-pc de una cabina) pareciera existir. Ahora
> si va o no en tu modelo, depende de tu cliente (el profesor).No te
> compliques, si ves que no te cierra, preferible que no este (o tratar
> de resolverlo de otra manera, despues podes refactoriar), por lo menos
> asi pienso yo.
Mucha razón!, algo que tengo que hacer después es poner una hoja con
"consideraciones", donde se aclare que es lo que está incluído y que
no en el trabajo, sobre todo en los puntos que quedan abiertos en el
enunciado.
>
> Por como pinta que va quedando, te tiene que ir bien, estas apuntando
> mas de lo que se pide en la facultad, buen trabajo. despues contanos
> que se siente que te pongan un 10 :)
Gracias! ojalá que sea esa la nota! en realidad trato que mi relación
con Smalltalk no quede en este practico, me interesa más aprovechar el
tiempo que tengo que dedicarle al práctico para aprender Smalltalk que
si la nota es un 7,8 o 9....
Por otro lado, una de las cosas que tenemos que hacer en este práctico
es agregar dos casos de uso adicionales a los que se piden, así que
después tengo que ir analizando que cosas se le pueden
incorporar...por otro lado que sea lo más parecido a la realidad
también es una de las cosas que me motiva a dedicarle tiempo.
Gracias Nuevamente!
Saludos,
Marcelo
entrada
GallegO ha escrito:
Muchas Gracias GallegO! muy clara tu explicación! sobre el tema del
ListView, String, y Diccionarios que mencionas seguramente pregunte un
poco más cuando llegue a la parte gráfica...por ahora estoy
concentrado en terminar de definir el modelo de objetos y a partir de
ahí programar la lógica y las pantallas.
Con respecto al WindowBuilder, tengo curiosidad de ver como trabaja,
asi que voy a intentar investigar un poco más y ver como se engancha
con VS 3.0.1...
Gracias Nuevamente.
Saludos,
Marcelo
> Saludos
> GallegO