Libros de UML, patrones con ejemplos en C#

[nesto...@gmail.com]

Que tal amigos de AltNet

 

Estoy buscando libros de UML Y PATRONES pero con ejemplos de C#.

Alguien sabe de algún BUEN libro para comprar ON LINE en pdf EN ESPAÑOL (me cuesta el inglés un poco jeje), o algún enlace con manuales al respecto.

Les agradecería me dieran esa información, porque como uno aquí en el foro me aconsejo “Es mejor saberse bien los conceptos y lo que hay detrás de cada implementación o Patrón, que saberse de memoria la sintaxis de un lenguaje especifico”.

 

Desde ya muchas gracias!!.

 

Atte.

Néstor Rodríguez

 

[Jorge Fioranelli]

Hola Nestor,

Me parece que no hay nada que cumpla con todos esos requisitos (estas pidiendo bastante).

El libro de Craig Larman cumple con la mayoria:

UML: si

Patrones: si (los principales)

Español: si (la 2da edicion esta mejor traducida que la primera)

Bueno: si, yo lo lei hace varios años y recuerdo que me gusto mucho

PDF: no se si estara disponible

C#: no, pero no vas a tener problemas en entender el codigo

El libro es muy bueno para formar una buena base de diseño orientado a objetos y tiene buenos ejemplos. 

Muy recomendado. Una vez que entendes los conceptos, es muy facil de aplicarlos a cualquier lenguage.

Saludos

JorgeF

2013/3/1 <nesto...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "AltNet-Hispano" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a altnet-hispan...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a altnet-...@googlegroups.com.
Visita este grupo en http://groups.google.com/group/altnet-hispano?hl=es.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Walter Poch]

+1 a Larman, están en Java los ejemplos, pero lo importante es la idea. 

Igual Nestor, tomalo como base, porque generalmente luego de aprender patrones, te enfermas de "patronitis" y tratas de implementarlos en todos lados, lo que lleva generalmente al mal uso de los mismos. En mi opinión son una guia, pero para aplicar con juicio, y sirven mucho para comunicar ideas, ahí es donde mejor los he aprovechado.

Saludos,

--

Saludos,

Walter G. Poch
--------------------------------------------
Cell: +54 (9 341) 6836871
walte...@gmail.com

[Vicenç Garcia]

Menos en el tema español, esto está muy bien: http://www.dofactory.com/Patterns/Patterns.aspx

2013/2/28 Walter Poch <walte...@gmail.com>

--
Vicenç García
http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

[Miguel Madero]

Head First Design Patterns es muy bueno y super didactico. Aunque no cubre UML y no se si este en español (quien realmente usa UML en estos dias?). Los conceptos de patrones de diseño aplican a C# practicamente igual que los ejemplos del libro que estan en Java. Online puedes encontrar todos los ejemplos en C#, pero el codigo Java te va a hacer sentido

Miguel

2013/2/28 Vicenç Garcia <vincen...@gmail.com>

[Juanma]

Yo te recomendaría el clásico,  "Design Patterns: Elements of Reusable Object-Oriented Software" de GoF, que creo que tiene edición español (http://www.cuspide.com/isbn/8478290591).

Por cierto, es curioso (y triste) que sea más sencillo encontrar páginas para descargar libros en español "piratas" que páginas para comprarlos.

2013/3/1 Miguel Madero <m...@miguelmadero.com>

--
Blog: http://blog.koalite.com

[Lester Quintero]

+1 a Head First Design Patterns un buen libro, me gusto mucho la forma en como plantean las cosas y aprendi y me rei mucho (little grasshoper, esta fue la frase dentro del libro que me mato de la risa).
Cierto que los ejemplos estan en Java pero son bastante entendibles y faciles de portarlos a C#.

[Fernando Claverino]

Hola gente,

Algo que me gusta de head first es que explica los patrones a partir de principios de diseño. En lugar de decir problema: bla, bla bla, solución: strategy, muestra cómo a partir de hacer refactor a pasos chicos siguiendo principios de diseño, se llega a aplicar naturalmente el patrón.

Además, está escrito y diseñado de una forma amigable p/el cerebro que favorece el aprendizaje.

saludos!

2013/3/1 Lester Quintero <lester.q...@gmail.com>

[nesto...@gmail.com]

Cuantas sugerencias, gracias a todos, ahora ya tengo para leer y bastante.

Una pregunta Miguel, como es eso de que no se usa UML en estos días (inferido de tu pregunta), bueno yo recién entro en este mundo del UML, pero ya NADIE LO USA?, llegue tarde al UML?, hay otra cosa ahora?

Bueno fueron varias pregunta al final jeje.

 

Gracias de nuevo por las sugerencias.

 

Atte.

Néstor

[Angel Java Lopez]

Dos comentarios cortos:

Creo haber visto que el Head First tenia una edicion en castellano. Lo
habre visto mas de media decada atras en alguna vidriera de Cuspide,
aca en Buenos Aires.

Yo hace rato que no uso UML (una decada?)

Para contestar a: "Que hay ahora?", Nestor, te preguntaria, "que hay
ahora para QUE?". Que es lo que necesitabas?

Nos leemos!

Angel "Java" Lopez
@ajlopez

2013/3/1 <nesto...@gmail.com>:

[Martín Salías]

Hola, Néstor.

Siguiendo la pregunta del Maestro sobre la tuya: ["¿Que hay ahora?" - ¿para qué?]...

Si la duda es que se usa (bueno, al menos en general en el ambiente de esta comunidad) para modelar, yo diría que mientras UML nunca terminó de cubrir las expectativas que generó como "el" mecanismo de diseño, aunque mucha gente (aún "agilistas" como Fowler o Uncle Bob lo usan un poco), hace tiempo que muchos venimos usando el código mismo como método de diseño, y más específicamente, TDD.

En su momento UML surgió como intento de poner una visión de más alto nivel al diseño de componentes y aplicaciones para no zambullirse derecho en el código porque no teníamos la disciplina suficiente como escribir código de manera iterativa e incremental. TDD te da todo eso, en mi humilde opinión.

Saludos,

---
Martín Salías

2013/3/1 <nesto...@gmail.com>

[Alpha]

Allo, me parece muy bueno el punto que expone Martín y quiero agregar (y un poquito disentir) de ello.

Es verdad que UML servía el propósito de modelar, pero como todo bien lenguaje, también servía el propósito de comunicar. UML permitía diseñar y exponer cómo es/sería el comportamiento de un sistema para exponerlo a quienes no comprendieran esa tecnología en particular, o sin necesidad de la sintaxis de ningún lenguaje específico.

Hoy mismo los patrones se expresan siempre como modelos UML porque no importa en qué lenguaje se implementen, el diseño genérico que UML le da es universal.

Creo que TDD sirve otro propósito que medianamente se solapa con el primero (modelar), pero son dos cosas muy distintas. Partiendo de que uno es un lenguaje y otra una metodología, creo que uno nunca podrá reemplazar a otro porque no fueron pensados para lo mismo.

Saludos.

2013/3/1 Martín Salías <mar...@salias.com.ar>

[José F. Romaniello]

Ademas la idea de UML era poder modelar cualquier cosa incluso proyectos que no fueran de software, por que iba a ser un lenguaje en el que vos haciendo actividad X podías acordar con tu cliente que no hablaba X.

En la facultad me decían que UML era bueno por que el cliente generalmente no entendía nuestra actividad. La realidad me indica que UML fracaso por que ni si quiera los programadores podían entenderlo, mucho menos iba a entenderlo un usuario final/cliente. Proba darle un diagrama de clases a alguien que no esta en nuestra profesión y preguntarle ¿Estas de acuerdo con que hagamos esto?. Ok, es muy granular? probemos con algo de mas alto nivel, un diagrama de casos de usos con actores y flechas y circulos... ¿ Estas de acuerdo con que hagamos esto ?

Coincido que a veces es más facil involucrar a una persona con tests, por supuesto de alto nivel "cuando facturo en tal condición, si el cliente es tanto, entonces se aplica un IVA de 21%"... y si le preguntas a tu cliente de proyecto de software "estas de acuerdo con esa premisa?", puede ser mucho mas provechoso.

Otras herramientas de diseño que ayudan MUCHISIMO y en mi opinión no se valoran tanto son las herramientas de mockup, nada como mostrarle al cliente como va ser una pantalla o imprimirse un reporte

Bueno, esas son algunas opiniones sobre UML :) 

saludos,

[nesto...@gmail.com]

Es que para desarrollar en ORIENTADO A OBJETOS me decían que se aprende
mejor con UML, y con la pregunta ¿Qué hay ahora? Me refería a si hay algo
"mejor" que UML o algo nuevo, por ejemplo divagando un poco algo así como
UML PlusII recargado!! Jajaja.
Desde ya gracias por la orientación y voy a leer más de UML, pero he aquí el
dilema, según los comentarios, ¿vale la pena decantarse por UML? o ¿tiene
alguna ventaja real hacer primero el UML antes de empezar a programar?.

Recuerden que soy Nuevo en esto, y desde ya gracias por la comprensión y
paciencia :).

Atte.
Néstor

-----Mensaje original-----
De: altnet-...@googlegroups.com [mailto:altnet-...@googlegroups.com]
En nombre de Angel Java Lopez
Enviado el: viernes, 01 de marzo de 2013 10:58

[Martín Salías]

Sigo opinando lo mismo, y aclaro que no digo que UML y TDD sean "lo mismo", sino que son dos maneras de encarar UN problema que es el diseño de componentes y aplicaciones.

Como dice José, UML tampoco es tan bueno para trasmitir ideas. Los tests, en mi opinión, son mucho mejores, si usás algo como RSpec.

Saludos,

---
Martín Salías

2013/3/1 <nesto...@gmail.com>

Es que para desarrollar en ORIENTADO A OBJETOS me decían que se aprende

[Daniel Calvin]

Ademas, del ademas....

Yo uso mucho UML:

Para diseñar? NOP

Para especificar? NIP

Para Transmitir ideas? me resulta excelente, ( sobre todo con personas no técnicas )

Para documentar procesos? si se aplica un criterio minimalista, donde el detalle es en el lenguaje del dominio y sin caer en implementacion, diagramas de secuencia y casos se uso de grano grueso ( muy macro ), me resulta muy bueno.

Para darle un contexto, eso es lo que siempre marca la diferencia a mi entender (el contexto), un dominio en el cual hay muchos sub dominios, con algunos puntos de contacto importantes, en donde hay que orquestar procesos que exceden sub dominios... ( trabajo en un banco, les aseguro es un infierno )

Imaginen ahora entender un proceso, o la colaboración entre varios sub procesos, mirando código..., donde el que conoce perfectamente un sub dominio no conoce mas que superficialmente los otros sub dominios...

UML, seguramente no es lo único, permite demostrar de forma simple estas cuestiones.

Si se imaginan diagramas de clases con 50 cuadraditos, cientos de flechitas, aclaro que no hablo de eso...

Adjunto a modo de ejemplo los diagramas de un doc de vision que detalla la funcionalidad a implementar en una aplicacion que integra dos sistemas disimiles. ( el proyecto es java, esta conformado por unos 15 jar distintos, unas 60 clases, ademas de los diagramas que incluyo aqui hay algunos de secuencia ( 6 o 7 ) , ahi termina la historia.

Para mostrar el alcance, para discutir con los responsables de otros sub dominios, consensuar  ideas y mostrar avance sirve mucho.

 Daniel Calvin

Daniel A. Calvin
Cooperator Team Member

[Jorge Fioranelli]

Hola Nestor,

Si bien es verdad que UML hoy en día no se usa tanto como en el pasado, sigue siendo la principal forma de representacion grafica que se usa en nuestra industria.

Si bien yo lo uso muy de vez en cuando, me parece que es muy importante que todos los desarrolladores sean capaces de entender al menos los diagramas basicos (clases e interacciones) ya que basta con agarrar cualquier libro arquitetura/patrones para encontrarte con varios diagramas UML. 

Ya sea que uses o no UML, tenes que ser capaz de entenderlo.

Abrazo

JorgeF

<Modelo de casos de uso.doc>

[Juan M Gómez]

Buenas, 
En ciertos contextos se está recuperando el uso de UML (aunque hace muchos años ya), en concreto de xUML (http://www.heron-language.com/xuml.html) ya que es una herramienta en las que se apoya MDA (http://es.wikipedia.org/wiki/Model_Driven_Architecture). 

Si a alguien le interesa el tema, hay una herramienta para .NET muy interesante en http://www.softfluent.com/products/codefluent-entities

Saludos

Juan M Gómez