¿Qué tan profundo debe un programador desarrollar su comprensión del Proceso Unificado y UML? [cerrado]

Sé que muchos lugares usan UML y el proceso unificado como su modelo de desarrollo ... pero hay muchos que no lo hacen. ¿Sería importante tener una comprensión más que básica y funcional de estos temas o sería mejor centrarse en desarrollar habilidades de programación en otras áreas (es decir, desarrollo del lenguaje, IDE, etc.)?

A menos que piense que mirar la pintura seca mientras el agua residual es un buen momento, ignore el Proceso unificado. Espera, ignorarlo no es suficiente. Temerlo Hasta donde sé, solo se usa en estos días en lugares enormes que están más allá de toda esperanza de eficiencia, calidad o cordura.

UML, por otro lado, puede ser una notación útil para conceptos de programación importantes. Obtenga el destilado UML de Martin Fowler , déle un vistazo y practique dibujar diagramas mientras piensa en el diseño. Es una habilidad que uso regularmente y me alegro de tenerla.

Tenga en cuenta que las personas intentan usar UML en exceso. La pizarra UML mientras se discuten las cosas es increíble. Un diagrama ocasional en la documentación publicada puede ser agradable. Pero la búsqueda de documentar toda su base de código en UML no tiene sentido y es un desperdicio. Y el deseo de "programar en UML" es idiota. Si te encuentras con gente así, huye. Pero primero, marca sus frentes con un diagrama de secuencia, para que el resto de nosotros esté debidamente advertido.

No gastes demasiado tiempo en UML. En mi equipo, soy el único que conoce muy bien UML y, por lo tanto, creo casos de uso, componentes, estados, despliegues y otros diagramas. Los otros miembros del equipo son mejores que yo para la codificación, pero no tan buenos para la diagramación UML.

El truco que utilizamos es centrarnos en el diagrama de clase a nivel de modelado para definir la estructura de la aplicación y también dejar que el desarrollador / arquitecto codifique como quiera. Luego fusionamos el modelo con el nuevo código y actualizamos el modelo en cada iteración. Realmente fácil y muy eficiente. Desarrollamos en Java con Omondo EclipseUML.

¡Recomendaría no usar ningún MDD que es para mí una verdadera mierda! Modeler intentará tomar más poder dentro del proceso de desarrollo, pero esto no creará ningún valor si intentan generar todo el código del modelo. El código pertenece al desarrollador / arquitecto pero no al modelador. UML solo debe ser una vista de los requisitos del proyecto (por ejemplo, caso de uso, secuencia, etc.) del proceso (por ejemplo, diagrama de estado o actividad), implementación (implementación, diagramas de componentes). El diagrama de clase debe tener una vista del código y el diagrama de clase UML solo debe usarse como un visor del código. La codificación Java debe respetar el enfoque de objetos y UML, que también es un lenguaje de objetos, es realmente útil para evitar la codificación basura y estúpida.

Lo más importante son las iteraciones del diagrama de clase entre modelo a código y código a modelo. Realmente no quiero decir sincronización en vivo, sino poder fusionar código y modelo en cada iteración. Uso Omondo EclipseUML y creo que son los únicos que combinan Java, entidades de bases de datos e ID de modelo. La fusión de ID es realmente un concepto poderoso y es perfecto para nuestros proyectos ágiles.

Mi recomendación es no comprar ningún libro. Debe tener un enfoque de objeto y usar lenguaje de diagrama de clase para visualizar sus objetos con el fin de crear mejores arquitecturas. Si uno de los miembros del equipo conoce UML, use los otros diagramas, de lo contrario el diagrama de clase sería suficiente.

El proceso unificado y UML son un conjunto de herramientas estructuradas de pensamiento y comunicación. Estas herramientas ayudan de varias maneras; tanto definiendo una forma de hablar sobre diseños como ayudándonos a trabajar a través de los detalles y facetas de nuestros diseños.

Mejorar su propio pensamiento es fundamental para completar los detalles de un diseño y para encontrar su camino hacia un producto sano y coherente. Las disciplinas personales lo ayudan a enfocarse, realizar un seguimiento de los detalles, pensar a fondo y recordar lo que piensa meses después.

Mejorar la forma en que se habla y se mejora el diseño es fundamental para lograr que un grupo de diseñadores avance más rápido. Las disciplinas grupales ayudan a obtener más del grupo.

Pero recuerde que tat UML y el proceso unificado son solo una de las muchas herramientas de pensamiento. Son razonables, pero pueden o no ajustarse a usted o su grupo (que es tan importante como cualquier otro factor).

En mi mente ahora hay una forma de evitar UML. Consigue un libro y aprende. Lo necesitas para:

• lee libros técnicos que usan UML (hay muchos)
• úselo como herramienta de dibujo para discutir ideas / soluciones con universidades.
• Dése una forma rápida de visualizar la solución en la que está pensando y razone sobre ella.
• leer / razonar sobre diseños técnicos / funcionales en ciertas compañías

El proceso unificado creo que es una historia diferente, depende del empleador en el que se encuentre. Al menos leería un libro para saber de qué se trata y cuando llegue el momento en que realmente lo necesites para estudiarlo.

Espero que esto ayude.

No creo que necesite un conocimiento extremadamente profundo de UML, pero definitivamente debería poder mirar un diagrama y saber qué está sucediendo. Lo que DEBE tratar de obtener un conocimiento profundo son diferentes patrones de diseño (compre un libro). Cuando se te ocurran tus propios diseños, te ayudará a conocer tanto el patrón de diseño como el patrón UML, incluso si realmente no lo dibujas. También lo ayuda a comprender un diagrama UML cuando lo ve, porque podría entender un poco mejor por qué el UML se ve así.

He estado en este negocio desde 1987 y las únicas veces que he tratado con UML y el Proceso Unificado fueron algunas ocasiones en las que a un consultor engreído le pagaron mucho dinero para forzar a alimentar al personal con todas las minucias de estos sobrevalorados, metodologías exageradas y tendenciosas. A raíz de cada intento de aplicar esta basura sin adulterar, terminamos generando suficiente documentación obsoleta casi de inmediato para llenar la Biblioteca del Congreso hasta desbordarse y más allá, al mismo tiempo que ralentizamos el diseño y el desarrollo de nuestros proyectos de manera inconcebible.

Si el producto de su empresa se va a medir en libras de papel y / o el tamaño de la documentación, nunca se leerá más de una vez (si es que es así), y será para siempre obsoleto, y esa será la base sobre la cual usted son pagados, entonces por todos los medios, vete por completo con esta basura.

De lo contrario, corre gritando por las colinas con la primera mención de UML y UP. O mejor, vencer a la primera persona que lo convierte en una pulpa.

Puede mencionar que podría usar UML SIN el proceso unificado. Uso mucho UML al mismo tiempo que la programación, pero para mí es importante ser práctico, no solo usarlo porque "es una herramienta nueva y brillante".

Los diagramas de clases, los casos de uso y los diagramas secuenciales son mis favoritos. No necesito usar otros tipos de diagramas con tanta frecuencia como estos.

Muchas empresas no utilizan el proceso unificado / racional.