Tengo una duda dudosa (?)

El tema es este, tengo varias tareas que no necesariamente se ejecutan todas, y definitivamente no van en paralelo.

Como las grafico ?

Tengo que hacer "desiciones" en cascada ? es decir :

¿ Realiza tarea 1 ? SI -> hacer tarea1
No -> ¿Realiza tarea 2 ? SI -> hacer tarea 2
No -> ¿Realiza tarea 3? ....

Lo cual es un bodrio.

Entonces volvemos a la pregunta:
¿ Se hace asi o hay alguna forma mas potable para marcarlo ?


Hay una cuestion mas, porque como no vi en la cursada lo de diagrama de actividades capaz estoy mandando fruta.
Las "actividades" serian las funciones del sistema ? es decir, ¿ los casos de uso ?
En caso de que no sean, ¿ como las detecto ?

Es lo del final del 3/12/11

Gracias

En el diagrama de actividades podes usar un Rombo que vendria a funcionar como un IF, o una "decision" , cual diagrama de flujos o cursograma.

De ahi las podes ir separando segun un resultado y determinar el camino a seguir

Cita:Las "actividades" serian las funciones del sistema ? es decir, ¿ los casos de uso ?
En caso de que no sean, ¿ como las detecto ?

En un diagrama de actividad graficas un conjunto de acciones. Lo podes usar para, por ejemplo, describir una regla de negocio compleja (un caso de uso complejo)


Te adjunto esta ppt de UML que seguro te va a servir

Genial, gracias.


Una pregunta mas, si el enunciado no es claro en cuanto a los pasos a seguir para representar al sistema (para el diagrama de actividades), ¿como lo hago?


Por ejemplo, de este enunciado (final del 3/12/11), al menos como empezar, como detectar las actividades

Lo tuve que poner en un RAR xq no me dejaba subir la imagen sola (bullshit de 500k limit)

  0001.rar (Tamaño: 1,14 MB / Descargas: 109)

me suena raro qiue te pida de todo el sistema. Esto te obliga a abstraerlo, o a qiue te quede gigantesco

deberias hacerlo teniendo en cuena los pasos que debe seguir un cliente para poder alquilar una maquina. UN ejemplo de como arrancarias seria:

- consultar catalogo
- Eligio producto ?Si --> seguir; no--> salir sistema
- El cliente esta cargado ? Si --> seguir; no --> cargar y luego seguir
- Aca haces validaciones varias (la maquina no este en uso, no esta reservada, etc)
- Haces comprobante
- Lo emitis
- Marcas como ocupada/reservada la maquinaria

Fue de manera muy general, probablemente falten cosas.. pero espero que te oriente

Si,
me da una idea de como hacerlo.


Gracias!

Hablando de este ejercicio, ¿cómo harían los CU?

Yo pondría un actor Cliente y dos CU: 'Reservar maquinaria' y 'Alquilar maquinaria', ambos con un extend 'Dar de alta cliente'. Aunque sería medio raro tener un actor Cliente nada más, quizás tirar un Empleado Administrativo en vez de Cliente (aunque nunca habla de un empleado en el texto).

Sobre el diagrama de actividades haría uno para la reserva y otro para el alquiler. Y el diagrama de clases una clase Maquinaria, que conozca sus "operaciones", y a su vez la clase Operación (de la cual heredan Reserva y Alquiler) que conozca quién fue el cliente que la realizó.

actor puse uno solo: cliente
los casos de uso que hice yo son:
consultar catalogo maquinas
registrar cliente
alquilar maquina
reservar maquina
renovar maquina (extend de alquilar maquina)
comprobar estado maquina (include de alquilar maquina y reservar maquina).

Del diagrama de clases, tenia bastantes dudas (porque no me acuerdo nada de pajadigmas) pero basicamente tenia las siguientes clases:
cliente
contacto
registro (de clientes)
catalogo maquina (contiene una coleccion con todas las maquinas de un tipo de maquina)
Alquilada y Reservada (que heredan de maquina)

El diagrama de actividades basicamente hice:
Consultar catalogo
eligio maquina ?
SI-> puede alquilar ?
SI-> Efectuar alquiler
NO-> puede reservar ?
SI-> efectuar reserva
despues de ambos efectuar hago un join
cliente esta en la base de datos ?
NO -> registrar
SI -> sigo hasta el join con el registrar y termina

Renovar yo lo tomé como que es lo mismo que hacer otro alquiler.

Ojo con subclasear la clase Máquina porque un objeto no puede ir cambiando de clase, y en este caso la máquina va cambiando de estado en el tiempo. Si vos instancías una Reservada vas a tener una máquina que va a estar siempre reservada. Tendrías que armarte una clase Estado y esa sí subclasearla en Reservada, Alquilada y Disponible.

(09-12-2011 20:40)Harmonium escribió:  Renovar yo lo tomé como que es lo mismo que hacer otro alquiler.

Ojo con subclasear la clase Máquina porque un objeto no puede ir cambiando de clase, y en este caso la máquina va cambiando de estado en el tiempo. Si vos instancías una Reservada vas a tener una máquina que va a estar siempre reservada. Tendrías que armarte una clase Estado y esa sí subclasearla en Reservada, Alquilada y Disponible.

Totalmente! Also known as State jaja

claro, patrones.

mi idea era una vez que el objeto cumplia su objetivo destruirlo y armar uno nuevo

No entiendo lo de "Destruir un objeto".....

Calculo que podés hacer que quede sin referencias y se lo lleve el Garbage Collector, pero tenés que crearte un nuevo objeto copiando los atributos del anterior, cosa que no es el fin de la programación orientada a objetos.

Off-topic:

Che ustedes dan mañana todos el final ? sale mini juntada ?

(09-12-2011 23:07)Harmonium escribió:  pero tenés que crearte un nuevo objeto copiando los atributos del anterior, cosa que no es el fin de la programación orientada a objetos.

Podés hacer un clon o tener un Prototype y listo, no es cuestión de si es o no el fin de la POO.

SI señor !

prototype !

es mi clase catalogo, con una coleccion de maquinas que si se alquilan o reservan se crean objetitos de la clase correspondiente

El tema de una clase "disponible" es que seria abstracta, lo unico que haria seria pasar a reservada o alquilada, para luego volver a disponible.
No es mala idea, de hecho es mejor que dejar tirado al objeto y que te lo barran (si, con destruir me referia a que le lo saque el GC).

Pero que se yo, uno agarra y empieza:

Aca tengo un patron prototype, por aca un state, aca un singleton !
Ya esta, 3 patrones juntos y para ellos sos un crack.