Ir al contenido


Foto

Ejercicios de uml y patrones


  • Por favor identifícate para responder
7 respuestas en este tema

#1 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 28 febrero 2015 - 11:39

En la universidad tengo que rendir un final con ejercicios como este:

Una biblioteca tiene copias de libros Estos últimos se. Estos últimos se caracterizan por su nombre, tipo (novela, teatro, poesía,ensayo), editorial, año y autor. Los autores se caracterizan por su nombre, nacionalidad y fecha de nacimiento. Cada copia tiene un identificador y puede estar en la Cada copia tiene un identificador, y puede estar en la biblioteca, prestada, con retraso o en reparación.Los lectores pueden tener un máximo de 3 libros en préstamo. Cada libro se presta un máximo de 30 días, por cada día de retraso, se impone una “multa” de dos días sin  posibilidad de coger un nuevo libro.
Realiza un diagrama de clases y añade los métodos necesarios para realizar el prestamo y devolución de necesarios para realizar el prestamo y devolución de libros.

Es decir armar diagramas de clases, tambien con patrones, ejercicios tales como identificar un patron dado un codigo y/o decir que patron utilizaria.

El caso es que no encuentro ejercicios iguales como el de la biblioteca, alguien me puede ayudar?
  • 0

#2 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 02 marzo 2015 - 04:19

Hola giulichajari, Puedes practicar estos tipos de ejercicios de forma indirecta. En lugar de buscar problemas de forma textual, hazlo libre.
Es decir, imagina cierto emprendimiento, limítalo en cierto contexto o ambiente. Y pregúntate: ¿Que tipo de sistema podrían necesitar y/o de que forma ayudarles?
Entonces de esa forma lo que uno piensa es en restaurants, supermercados, gasolineras, estudios contables o de abogados, todo lo que se te ocurra.
Así hacía yo, imaginaba contextos y luego diseñaba mis propuestas.

Lo de patrones lamentablemente se hace con la práctica constante. En la medida en que uno va armando el análisis y formando su propia técnica. Como consejo primero piensa con GRASP, luego en GoF y luego "reorganiza" tus ideas con el resto de ellos.
Reconocer patrones por código es algo que yo, en lo personal, no recomendaría hacerlo (aunque admito que en muchas veces lo he hecho y resulta de interés y si... hay que saber hacelo). Algunos patrones se pueden apreciar fácilmente, otros son bastantes abstractos... Se pone más difícil cuando en un mismo conjunto de clases intervienen más de un patrón. Por lo general los patrones vienen con 2 o 3 más.

Un motivo por el que puede ser difícil verlo en código es que nada impide nombrar a los métodos y clases que hace a un patrón con un nombre adecuado al contexto en el que se encuadra el diagrama y no con el nombre que sugiere (o el que se acostumbra usar en) el patrón. Por ejemplo, estoy diseñando un video juego tipo Diablo o PoE en donde habrá un especie de portal que crea criaturas májicas mientras no sea destruído. Puedo concebir a este portal como una Fábrica o Factoría, pero en código es probable que no la llame TFactory sino TMagicPortal. O si estoy aplicando el Patrón Observador para que un monstruo que cumpla rol de Jefe pueda dar aviso a sus subditos en lugar de llamar al método Notify() que sugiere el patrón, lo voy a llamar HelpMe().
Asi que es algo difuso hablar de reconocer patrones por el código.

Por eso yo, si fuera profesor, en lo posible evitaría llegar a esto. Otro peligro de esta "ingeniería inversa" es que si no se presta demasiado cuidado es posible que por generar las abstracciones (clases) sin tener un contexto bien delimitado terminemos dando en un ejercicio otros patrones ocultos que no queríamos poner. Repito: los patrones no vienen solos.

Distinto es si nos apoyamos en UML. Allí si es posible apreciarlos mejor. Aunque tampoco es que esperes que hay una única respuesta... como he dicho: los patrones por lo general vienen de a varios.

¿Porqué no vienen solos? Porque todo patrón que no sea GRASP, como los GoF, son combinación, o una reformulación, o especialización de los GRASP. Una lección tardía que terminan aprendiendo los estudiantes (y no tan estudiantes) es que TODO patrón que imagines puede ser "escrito" con los GRASP y/o GoF. Fabricacíón Pura (ojo, no confudir con Factoría ni con Fábrica Abstracta) e Indirección son 2 patrones que lo deberías poder ver en la enorme mayoría (sino todos) los casos. Obviemos Alta Cohesión y Bajo Acoplamiento y Variaciones Protegidas... esos SIEMPRE pero SIEMPRE están.

Este es mi consejo final.

Espero poder haberte ayudado en algo.

Saludos y éxitos en el final.
  • 0

#3 FGarcia

FGarcia

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 687 mensajes
  • LocationMéxico

Escrito 02 marzo 2015 - 05:31

Sabia que Delphius era el bueno!!!  <:o)

Aunque como siempre....No entiendo ni jota!!!!!

Es como si me hablaran de física astronuclear cuando apenas si se la segunda ley de Newton  :embarrassed:
  • 0

#4 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 02 marzo 2015 - 06:33

Sabia que Delphius era el bueno!!!  <:o)

Aunque como siempre....No entiendo ni jota!!!!!

Es como si me hablaran de física astronuclear cuando apenas si se la segunda ley de Newton  :embarrassed:


Gracias por el alago amigo.
No se me ponga triste, lo que he dicho tampoco es que sea algo tan complicado. Si admito que cuesta entenderle al principio pero luego con la práctica se vuelve natural. Lo que asusta en realidad es que los patrones son muchos y algunos son el "opuesto" del otro o una especialización y otros se aplican a áreas más específicas (como los patrones Mapper y Broker que aplican mayormente en la Frameworks de Persistencia, o NEP: Nombre El Problema no el lanzador que aplica en el mundo de las Excepciones)... actualmente superan los 200 (si no recuerdo mal) pero de ese número sólo apenas unas decenas son ampliamente estudiados.
Y como dije antes: con estudiar los más esenciales es posible armar cualquiera. Con estudiar los más esenciales (serán nomás de 20, 25) ya es posible cubrir el 99% de las necesidades actuales y futuras. El asunto es que el resto son patrones tan específicos que hasta se discute si tienen sentido. Hay estudiosos de Ingeniería del Software que han puesto alarma en esto y con su justa razón argumentan que han hecho de los patrones un monstruo. Y que por mucho aplicar patrones, se termina complicando algo que podría haberse hecho de forma más sencilla. A causa de esto es que ha nacido la corriente contraria: los anti-patrones.
Como todo en la vida, hay que saber encontrar el equilibrio. La patronitis es una enfermedad.

A pesar de esto, sugiero enormemente estudiar el tema. Bien usado ayuda enormemente a nuestros desarrollos.

No hay que temerles. Y no hay límites de edad ni de conocimientos para estudiarlos. Basta con saber POO para entrar en el tema.

Saludos,
  • 0

#5 tmsanchez

tmsanchez

    Advanced Member

  • Miembros
  • PipPipPip
  • 85 mensajes

Escrito 02 marzo 2015 - 06:56

Echale un ojo a esta liga: http://edn.embarcade...m/article/31863

Otra opción es que consigas el libro "Aprendiendo UML en 24" de Josep Schmuller. A lo largo de todo el libro van desarrolando varios ejemplos de ese tipo.  A partir de la mitad del libro desarrolla un proyecto completo.

Saludos.
  • 0

#6 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 02 marzo 2015 - 07:23

Echale un ojo a esta liga: http://edn.embarcade...m/article/31863

Otra opción es que consigas el libro "Aprendiendo UML en 24" de Josep Schmuller. A lo largo de todo el libro van desarrolando varios ejemplos de ese tipo.  A partir de la mitad del libro desarrolla un proyecto completo.

Saludos.

Yo la verdad huyo de libros de ese estilo. No se aprende en 24 horas, ni en 24 días. Por regla general, intentan hacer las cosas más simples de lo que son y por ser breves omiten temas que merecen su debida atención. Y sobre evitaría recomendarlo para el dictado o el cursado de una cátedra. A lo sumo lo pondría como Bibliografía Complementaria pero de ningún modo en la fuente principal de estudio.
Para educar se hace bien o no se hace. Mínimo hay que leer UML y Patrones de Craig Larman, pero no sin antes estudiar UML. Y para esto no hay mejor referencia que el de sus 3 creadores. Sobre Patrones lamentablemente no he tenido por el momento el placer de tener a mano más referencia física que de UML y Patrones, pero en la web me he vaido mucho de OODesign.com y de SourceMaking y de wikipedia.

Tengo algunas fuentes pendientes de lectura. Me tengo que fijar en los libros que anoté en mi lista. Espero con el dinero que recupere en los próximos días destinar algo para ver si finalmente puedo comprarme uno.

Con decir que al libro de UML Gota a Gota le tengo sus paréntesis. Y eso que es ampliamente citado y puesto como material de estudio en los programas. Quisiera pensar que hay ediciones nuevas... la edición que yo tengo en mano data de la época de UML 1.0 y 1.1 cuando UML estaba por demás fresco. Pero no he visto haya sacado más.

Pero claro, gustos son gustos.

Saludos,
  • 0

#7 tmsanchez

tmsanchez

    Advanced Member

  • Miembros
  • PipPipPip
  • 85 mensajes

Escrito 02 marzo 2015 - 09:44

"El lenguaje unificado de modelado", Grady Booch, James Rumbaugh, Ivar Jacobson. Editorial Addison Wesley.
https://books.google...ved=0CCcQ6AEwAQ
  • 0

#8 giulichajari

giulichajari

    Advanced Member

  • Miembros
  • PipPipPip
  • 477 mensajes

Escrito 03 marzo 2015 - 05:23

Muchas gracias a todos por las respuestas.

Encontre por ejemplo:

http://astreo.ii.uam...rcicios_UML.pdf

http://www.infor.uva...os_patrones.pdf

http://dis.um.es/~jm...atrones2005.doc

Nosotros vimos y me evaluaran los creacionales y estructurales y el uml 2.0, pero tratare algunos de estos ejercicios.
Gracias
  • 0




IP.Board spam blocked by CleanTalk.