¿Con qué frecuencia usa UML formal?

Usé MUML ad-hoc (lenguaje de modelado inventado) para diseñar y explicar el sistema con bastante frecuencia. Se parece a UML y tiende a entenderse bastante bien.

Sin embargo, he tenido uno o dos profesores que insistieron en el uso de UML estricto y formal, lo más cercano posible a la especificación. Siempre sospeché que UML estricto no era realmente tan común como afirmaban. Entonces, ¿qué tal? ¿Con qué frecuencia dibuja diagramas completos que usan todas las terminaciones de línea adecuadas, multiplicidad, símbolos de tipo de miembro, etc.?

Nunca.

Diablos, han pasado años desde la última vez que creé un UML. Los diagramas lineales en pizarras y trozos de papel no cuentan.

De hecho, acabamos de eliminar la única pregunta de UML de la guía que usamos durante las entrevistas, porque ninguno de nosotros realmente se preocupaba por las respuestas.

Utilizo la cantidad suficiente de UML (tanto en términos de los tipos de diagramas como del contenido de la información en el diagrama) para expresar mi punto de vista y permitirme a mí oa alguien más implementar el sistema o subsistema. Y la única razón por la que uso UML es porque es un conjunto de símbolos ampliamente conocido que cada uno significa algo muy específico, por lo que no hay ambigüedad: cualquier ingeniero de software debería poder ver el diagrama y comprender lo que estoy tratando de decir sobre el sistema.

Irónicamente, se supone que UML es flexible.

En el mundo real, no se supone que es un ejercicio pedante en hacerlo una manera correcta. Se trata de comunicar y documentar efectivamente un sistema / proceso / idea.

Para responder a tu pregunta, estoy con los demás. Nunca he utilizado completamente UML formal completo.

Usé UML muy regularmente durante aproximadamente cuatro años para un producto que generó todos (la mayoría) de sus esqueletos de código de Rational Rose.

En los últimos cinco años se han inventado más "cajas y flechas" en su mayoría en el acto y, por lo general, suficientes para transmitir la idea general. Corregir formalmente UML solo unas pocas veces durante este tiempo.

Sin embargo, he tenido uno o dos profesores que insistieron en el uso de UML estricto y formal, lo más cercano posible a la especificación.

Pregúntele a su profesor cuándo fue la última vez que utilizó ese enfoque en un sistema real. Seriamente.

Intento ser lo más formal posible cuando se trata de UML, pero solo si / cuando tiene sentido. Los fanáticos a ambos lados del espectro (desde vaqueros hasta formalistas tensos) no entienden eso.

Hay contextos en los que un enfoque menos rígido (como el que usted usa personalmente) es el mejor enfoque a seguir. Un buen ejemplo es para sistemas pequeños o cambios, donde los requisitos son pequeños y no están completamente definidos; el grupo a cargo es eficiente y efectivo; Es más importante sacarlo que hacerlo perfecto. Se realiza de forma iterativa y algunas deficiencias son aceptables.

O tal vez se encuentra en una etapa en la que está haciendo guestimation y bocetos en lugar de una fase de modelado formal completo. Esos son ejemplos que me vendrían a la mente.

En otras ocasiones, necesita un enfoque UML formal rígido. Por ejemplo, puede estar obligado contractualmente; tiene una gran cantidad de desarrolladores en varios equipos (posiblemente distribuidos); el alcance del proyecto puede ser en años; es un sistema muy grande (que incluye componentes de software y hardware); el costo del fracaso es alto, etc.

En otras ocasiones , debe usar algo más en lugar de UML (modelos matemáticos formales reales como redes de Petri, CSP o lógica temporal). Ejemplo de esto son sistemas en tiempo real, sistemas donde las fallas son catastróficas (dispositivos médicos) o donde está obligado contractualmente (es decir, como en Europa cuando desarrolla sistemas de transporte).

Todo depende de las circunstancias y de lo que esperamos obtener de cada enfoque. Un profesor que no se apega a la formalidad es simplemente ser un fanático ciego. El mundo de la ingeniería no es una dicotomía negro-n-blanco, correcto / incorrecto. Es un mundo de intercambios inteligentes.

Si eres lo suficientemente inteligente como para usar un modelo informal e informal de una manera que sea efectiva y apropiada para hacer el trabajo, entonces que así sea. Del mismo modo, se espera que usted reconozca cuándo NO utilizar un enfoque informal y / o cuándo NO utilizar uno formal.

Dicho esto, tienes que jugarlo de oídos con los profesores. Dales un hueso para que te den una calificación, y si eso significa finalmente inclinarse ante su fanático fanático, está bien. Usted sabe lo que funciona para usted y, con suerte, sabrá cuándo usar qué y cómo en el mundo real.

Como parte de mi investigación de doctorado, estudié cómo los diseñadores experimentados usan UML en colaboraciones de diseño (aunque en entornos artificiales).

Mis hallazgos fueron que las metáforas y notaciones de UML son prestadas, pero hay poca adherencia a la rigurosidad de las herramientas.

Más adelante, algunos modelos pueden transformarse iterativamente en UML más estrictos, a menudo cuando una herramienta CASE exigente está involucrada con el propósito de generar código.

Las advertencias habituales de la investigación académica se aplican, por supuesto :)

Un enlace al resumen en papel y al documento en sí (si no tiene acceso a ACM) .

Aparte de eso, recomiendo encarecidamente el "Agile Modeling" de Ambler.

Usamos UML formal para la generación de código de un ORM en hibernación. La mayoría de las otras cosas son informales o de pizarra. Solo es importante para nosotros con la generación de código porque la falta de formalidad lo rompería.

Depende de la industria en la que se encuentre. Si trabaja para clientes que requieren revisiones técnicas frecuentes (por ejemplo, PDR, CDR, etc.), prefieren algún tipo de estandarización en lugar de sistemas de notación ad-hoc. En particular el trabajo del gobierno. Evita la falta de comunicación y la explicación inicial de 15 minutos de la notación que inventó.

Además, el hecho de que esté utilizando UML no significa que deba puntear cada i y cruzar cada t de acuerdo con el estándar. Eso es solo si desea hacer algún tipo de generación / ejecución automática de código. No conozco a nadie que haya hecho eso por más de 1 proyecto.

Por otro lado, si solo está trabajando para su empresa con un equipo de sus propios desarrolladores, ¿a quién le importa qué notación use? Sin embargo, si elige la herramienta adecuada, puede ser un ahorro de tiempo real.

Con todo lo dicho, le resultará difícil sobrevivir en algunas industrias sin poder diseñar con UML. En otras industrias, nunca lo verás.

Además, creo que también encontrará una correlación entre aquellas industrias que requieren que el diseño sea correcto porque los costos de corrección son correspondientemente altos por ser grandes usuarios de UML; frente a las industrias que los costos de las correcciones de diseño son poco más que cambios en la documentación / código como lugares donde UML probablemente nunca se usa.

En lo que respecta a la pregunta original. La mayoría de las universidades tienden a orientar la capacitación de sus estudiantes para las empresas que reclutan a sus estudiantes con mayor frecuencia. Si su profesor piensa que UML es importante, entonces no me sorprendería que muchas de las empresas que reclutan de su escuela usen UML. Por lo tanto, debe aprender a usarlo.

Cuando leí sobre UML probé esto en todos los problemas que tenía que resolver en mi curso de C ++. Afortunadamente, uno de los primeros ejemplos que probé fue describir una lista vinculada.
No funcionó
Dicho esto, junto con un buen proceso de modelado, UML es útil. Simplemente porque es para mejor o peor un estándar.
Me encantaría ver un lenguaje de descripción de la meta programación de plantillas. Creo que eso ayudaría mucho a entender lo que está sucediendo en <<<>>> -land

UML es doloroso si también prueba el desarrollo Model Driven. Quiero decir que UML es una notación gráfica muy útil solamente y todo lo demás es inútil. No gasto en modelado, pero uso UML todos los días para crear la estructura de mis proyectos. Lo que hago es dibujar rápidamente un diagrama de caso de uso básico en los niveles de requisitos, luego cambiar inmediatamente a diagramas de clase. Agrego la trazabilidad de requisitos entre los diagramas de caso de uso y clase. Mi diagrama de clases también crea código porque está sincronizado en vivo. No hay ninguna etiqueta en el código, todos los modelos se guardan en el modelo UML que se asigna al proyecto Java.

Creo el esqueleto de mi aplicación con pocos diagramas de clase, luego cambio al código. Una vez que terminé el código, lo fusioné con el modelo. Es un tipo de iteración entre el código y el modelo donde el código ejecuta el modelo. Entonces, mis diagramas de clase me dan un mayor nivel de abstracción y mi código, mientras que mi código me da mi implementación de lógica de negocios (por ejemplo, métodos).

El modelado UML requiere menos de 10 minutos por día, lo que se hace cuando necesito tiempo para pensar qué necesito desarrollar y cómo.

¡UML es genial, fantástico y realmente útil, pero el desarrollo basado en modelos es inútil!

Si estoy documentando un sistema que hemos implementado, entonces trato de establecerlo con UML formal completo. Pero el resto del tiempo, solo uso la cantidad necesaria para transmitir la idea. También me encuentro usando más DFD que UML, ya que parecen ser más apropiados para los sistemas que estamos diseñando últimamente.

Acabo de abandonar mi universidad supuestamente de primer nivel (al menos temporalmente) debido a su rígida insistencia en actividades de modelado visual excesivamente largas, tareas del foro, habilidades excesivamente redundantes que cualquier persona que creció cerca de las computadoras o alguna vez se ha burlado pensativamente hacia una interfaz de usuario sería lo suficientemente buena como para que la idea de endeudarse profundamente hiciera querer romper las cosas con absoluta frustración.

Tuve que elegir entre aprender lo que veía que exigían los trabajos de nivel inicial y junior y qué obstáculos CES establece para la acreditación ABET de la universidad, lo que hace que los tomadores de decisiones se vuelvan tontos cuando hay problemas evidentes con limitaciones de tiempo y expectativas poco realistas que revelaría una evaluación PERT. La universidad no practica lo que enseña.

En mi opinión, el Proceso Unificado tiene mucho mérito, pero toda la práctica de acuñar artefactos visuales, cualquiera que sea el lenguaje de modelado, es un poco ridículo. Un documento refinado iterativamente que contiene una lista seriada, tal como podría producirse con Word, Workflowy, Evernote, OpenOffice o nombrar un procesador de textos, es perfectamente capaz de documentar lo que requiere el Proceso Unificado. Algo en este simple jane puede ser trabajado fácilmente por múltiples usuarios, controlado por la versión, y si uno elige la herramienta adecuada para hacerlo, un equipo podría incluso trabajar en ello al mismo tiempo. Esto es mucho más fácil de hacer que cuando UML parecía un modo necesario de unir a las hordas.