¿Es UML práctico? [cerrado]

114

En la universidad he tenido numerosos cursos de diseño y orientados a UML , y reconozco que UML se puede utilizar para beneficiar un proyecto de software, especialmente el mapeo de casos de uso , pero ¿es realmente práctico? He hecho algunos términos de trabajo cooperativo y parece que UML no se usa mucho en la industria. ¿Vale la pena dedicar tiempo durante un proyecto a crear diagramas UML? Además, encuentro que los diagramas de clases generalmente no son útiles, porque es más rápido mirar el archivo de encabezado de una clase. Específicamente, ¿qué diagramas son los más útiles?

Editar: Mi experiencia se limita a proyectos pequeños de menos de 10 desarrolladores.

Editar: Muchas buenas respuestas, y aunque no es la más detallada, creo que la seleccionada es la más equilibrada.

Chris
fuente
4
Los resultados de una encuesta de 2013 revelan que no se usa tanto como los profesores de ingeniería de software esperan (!) Y revelan algunas razones por las cuales: oro.open.ac.uk/35805/8/UML%20in%20practice%208.pdf
Fuhrmanator

Respuestas:

47

En un sistema suficientemente complejo hay algunos lugares donde algunos UMLse consideran útiles.

Los diagramas útiles para un sistema varían según la aplicabilidad.
Pero los más utilizados son:

  • Diagramas de clases
  • Diagramas de estado
  • Diagramas de actividad
  • Diagramas de secuencia

Hay muchas empresas que juran por ellas y muchas que las rechazan rotundamente como una absoluta pérdida de tiempo y esfuerzo.

Es mejor no exagerar y pensar qué es lo mejor para el proyecto en el que se encuentra y elegir las cosas que sean aplicables y tengan sentido.

Pascal
fuente
83

Usar UML es como mirar sus pies mientras camina. Es hacer algo consciente y explícito que normalmente puedes hacer de forma inconsciente. Los principiantes deben pensar detenidamente sobre lo que están haciendo, pero un programador profesional ya sabe lo que están haciendo. La mayoría de las veces, escribir el código en sí es más rápido y efectivo que escribir sobre el código, porque su intuición de programación está ajustada a la tarea.

Sin embargo, no se trata solo de lo que estás haciendo. ¿Qué pasa con el nuevo empleado que llega dentro de seis meses y necesita ponerse al día con el código? ¿Qué tal dentro de cinco años, cuando todos los que trabajan actualmente en el proyecto se hayan ido?

Es increíblemente útil tener documentación básica actualizada disponible para cualquier persona que se una al proyecto más adelante. No defiendo diagramas UML completos con nombres de métodos y parámetros (MUY difíciles de mantener), pero sí creo que un diagrama básico de los componentes del sistema con sus relaciones y comportamiento básico es invaluable. A menos que el diseño del sistema cambie drásticamente, esta información no debería cambiar mucho incluso cuando se modifique la implementación.

Descubrí que la clave de la documentación es la moderación. Nadie va a leer 50 páginas de diagramas UML completos con documentación de diseño sin quedarse dormido en unas pocas páginas. Por otro lado, a la mayoría de las personas les encantaría obtener de 5 a 10 páginas de diagramas de clases simples con algunas descripciones básicas de cómo el sistema está armado.

El otro caso en el que he encontrado que UML es útil es cuando un desarrollador senior es responsable de diseñar un componente, pero luego entrega el diseño a un desarrollador junior para que lo implemente.

17 de 26
fuente
31
"¿Qué pasa con el nuevo empleado que llega dentro de seis meses y necesita ponerse al día con el código?" Errr ... ¿qué tal mirar el código? Esa es la única forma precisa y completa de ponerse al día con el código. También de la forma más natural, considerando que somos programadores. Considero que la noción de que tenemos que mirar un diagrama para entender el código es completamente risible y también deprimente que esta basura de alguna manera se haya generalizado.
BobTurbo
6
De acuerdo con BobTurbo, nunca he usado UML, especialmente el UML de otra persona. Siempre prefiero ir directamente al código.
James Adam
7
Descubrí que dibujar un diagrama de clases UML antes de embarcarme en la codificación me ha ahorrado tiempo. Me ha permitido visualizar fallas y fallas de diseño y discutirlas con mis colegas. Mejor aún, si se dibujan con herramientas CASE, generarán el código estructural básico de su aplicación. Entonces, la recuperación es triple.
Andrew S
1
@James Adam, no se supone que ningún diagrama reemplace la observación del código, pero en bases de código enormes (pruebe con millones de líneas de código) tener una visión general de más alto nivel del sistema puede ahorrar mucho tiempo y nervios.
serina
10
Una imagen vale más que mil palabras, incluso cuando es código, @BobTurbo. No veo ningún argumento racional en contra de esto, y eso incluye argumentos que comienzan con "Bueno, programadores reales ...". Si voy a tener una conversación sobre arquitectura con mi equipo, no voy a hablar con cinta adhesiva. 10 páginas de código fuente en una pizarra.
DavidS
34

Usar UML es como mirar sus pies mientras camina. Es hacer algo consciente y explícito que normalmente puedes hacer de forma inconsciente. Los principiantes deben pensar detenidamente sobre lo que están haciendo, pero un programador profesional ya sabe lo que están haciendo. La mayoría de las veces, escribir el código en sí es más rápido y efectivo que escribir sobre el código, porque su intuición de programación está ajustada a la tarea.

La excepción es por qué te encuentras en el bosque por la noche sin una antorcha y ha comenzado a llover; entonces necesitas mirarte los pies para evitar caerte. Hay ocasiones en las que la tarea que ha asumido es más complicada de lo que su intuición puede manejar, y necesita reducir la velocidad y establecer la estructura de su programa de forma explícita. Entonces UML es una de las muchas herramientas que puede utilizar. Otros incluyen pseudocódigo, diagramas de arquitectura de alto nivel y metáforas extrañas.

Marcus Downing
fuente
3
Lo extraño de este sitio web es que no hay forma de saber que estás citando a alguien en el primer párrafo y luego no estás de acuerdo con ellos ... pero sí, es cierto: el pseudocódigo también es una gran técnica de diagramación y se usa con mucha frecuencia. Las metáforas extrañas que involucran maderas, antorchas, etc. también son geniales.
Dan Rosenstark
no estoy de acuerdo en absoluto - si haces componentes complejos - uml es imprescindible
yehonatan yehezkel
18

El flujo de trabajo genérico y los DFD pueden ser muy útiles para procesos complejos. Todos los demás diagramas (ESPECIALMENTE UML) han sido, en mi experiencia, sin excepción una dolorosa pérdida de tiempo y esfuerzo.

Stu
fuente
16

Tendría que estar en desacuerdo, UML se usa en todas partes; en cualquier lugar donde se diseñe un proyecto de TI, UML generalmente estará allí.

Ahora bien, si se está utilizando bien es otra cuestión.

Como dijo Stu, encuentro que tanto los casos de uso (junto con las descripciones de los casos de uso) como los diagramas de actividades son los más útiles desde el punto de vista del desarrollador.

El diagrama de clases puede ser muy útil cuando se intenta mostrar relaciones, así como atributos de objeto, como la persistencia. Cuando se trata de agregar un solo atributo o propiedad, generalmente son excesivos, especialmente porque a menudo se vuelven obsoletos rápidamente una vez que se escribe el código.

Uno de los mayores problemas con UML es la cantidad de trabajo que se requiere para mantenerlo actualizado una vez que se genera el código, ya que hay pocas herramientas que puedan rediseñar UML a partir del código y pocas que lo hagan bien.

Samjudson
fuente
14

Calificaré mi respuesta mencionando que no tengo experiencia en entornos de desarrollo corporativo grandes (similares a IBM).

La forma en que veo UML y el Proceso Unificado Racional es que se trata más de HABLAR sobre lo que vas a hacer que de HACER realmente lo que vas a hacer.

(En otras palabras, es en gran medida una pérdida de tiempo)

Seibar
fuente
9
No voy a rechazarlo porque creo que es una buena respuesta, pero no podría estar más en desacuerdo. Cada vez que hago un diagrama de algo, me ahorro horas o meses de tiempo de desarrollo, y casi siempre me desarrollo solo (recientemente).
Dan Rosenstark
2
Hablar y escribir sobre lo que quiere hacer le ayuda a usted y a los demás a comprender y detectar posibles problemas antes.
Kamran Bigdely
12

Tíralo solo en mi opinión. UML es una gran herramienta para comunicar ideas, el único problema es cuando lo almacena y lo mantiene porque básicamente está creando dos copias de la misma información y aquí es donde suena. Después de la ronda inicial de implementación, la mayor parte del UML debe generarse a partir del código fuente; de ​​lo contrario, quedará desactualizado muy rápidamente o requerirá mucho tiempo (con errores manuales) para mantenerse actualizado.

Quisquilloso
fuente
Guau. ¿Qué tal una herramienta que mantiene el diagrama sincronizado con el código y viceversa, como Together?
Dan Rosenstark
1
El hecho de que UML se pueda generar a partir de la fuente significa, para mí, que no hay ningún beneficio en leer UML en lugar de simplemente leer la fuente. En otras palabras, es un desperdicio.
Marcus Downing
1
@MarcusDowning No, ayuda a los nuevos empleados de forma masiva. Es más rápido mirar UML que el código.
Kamran Bigdely
10

Co-enseñé un curso de proyecto de desarrollo de nivel superior en mis dos últimos semestres en la escuela. El proyecto estaba destinado a ser utilizado en un entorno de producción con organizaciones sin fines de lucro locales como clientes de pago. Teníamos que estar seguros de que el código hiciera lo que esperábamos y de que los estudiantes capturaran todos los datos necesarios para satisfacer las necesidades de los clientes.

El tiempo de clase era limitado, al igual que mi tiempo fuera del aula. Como tal, tuvimos que realizar revisiones de código en cada reunión de la clase, pero con 25 estudiantes inscritos, el tiempo de revisión individual fue muy corto. La herramienta que encontramos más valiosa en estas sesiones de revisión fueron los ERD, los diagramas de clases y los diagramas de secuencia. Los ERD y los diagramas de clases se realizaron solo en Visual Studio, por lo que el tiempo necesario para crearlos fue trivial para los estudiantes.

Los diagramas comunicaron una gran cantidad de información muy rápidamente. Al tener una descripción general rápida de los diseños de los estudiantes, pudimos aislar rápidamente las áreas problemáticas en su código y realizar una revisión más detallada en el acto.

Sin usar diagramas, hubiéramos tenido que tomarnos el tiempo para revisar uno por uno los archivos de código de los estudiantes en busca de problemas.

Jason Sparks
fuente
+1 Una buena visualización de los datos ayuda a exponer problemas y tendencias que de otro modo se oscurecerían con detalles irrelevantes.
Vlad Gudim
8

Llego a este tema un poco tarde y solo intentaré aclarar un par de puntos menores. Preguntar si UML es útil por ser demasiado amplio. La mayoría de la gente pareció responder a la pregunta desde el UML típico / popular como una perspectiva de herramienta de dibujo / comunicación. Nota: Martin Fowler y otros autores de libros sobre UML creen que es mejor usar UML solo para la comunicación. Sin embargo, hay muchos otros usos para UML. Sobre todo, UML es un lenguaje de modelado que tiene notación y diagramas asignados a los conceptos lógicos. A continuación, se muestran algunos usos de UML:

  • Comunicación
  • Documentación estandarizada de diseño / solución
  • Definición de DSL (lenguaje específico de dominio)
  • Definición de modelo (perfiles UML)
  • Uso de patrón / activo
  • Codigo de GENERACION
  • Transformaciones de modelo a modelo

Dada la lista de usos anterior, la publicación de Pascal no es suficiente, ya que solo habla de la creación de diagramas. Un proyecto podría beneficiarse de UML si alguno de los anteriores son factores críticos de éxito o áreas problemáticas que necesitan una solución estandarizada.

La discusión debe expandirse desde cómo UML puede ser sobre-eliminado o aplicado a proyectos pequeños para discutir cuándo UML tiene sentido o realmente mejorará el producto / solución, ya que es entonces cuando se debe usar UML. Hay situaciones en las que UML para un desarrollador también podría detectar, como Aplicación de patrones o Generación de código.

Ted Johnson
fuente
5

UML me ha funcionado durante años. Cuando comencé, leí UML Distilled de Fowler, donde dice "hacer suficiente modelado / arquitectura / etc.". ¡Solo usa lo que necesites !

Sean Kearon
fuente
4

Desde la perspectiva de un ingeniero de control de calidad, los diagramas UML señalan posibles fallas en la lógica y el pensamiento. Hace mi trabajo más fácil :)

Nick Stinemates
fuente
3

Creo que UML es útil, pero creo que la especificación 2.0 ha hecho que lo que una vez fue una especificación clara sea algo hinchado y engorroso. Estoy de acuerdo con la edición de diagramas de tiempo, etc., ya que llenaron un vacío ...

Aprender a usar UML de manera efectiva requiere un poco de práctica. El punto más importante es comunicarse claramente, modelar cuando sea necesario y modelar en equipo. Las pizarras son la mejor herramienta que he encontrado. No he visto ningún "software de pizarra digital" que haya logrado capturar la utilidad de una pizarra real.

Dicho esto, me gustan las siguientes herramientas UML:

  1. Violeta - Si fuera más simple sería un trozo de papel

  2. Altova UModel: buena herramienta para modelado en Java y C #

  3. MagicDraw: mi herramienta comercial favorita para modelar

  4. Poseidón: herramienta decente con una buena relación calidad-precio

  5. StarUML: la mejor herramienta de modelado de código abierto
Daniel Honig
fuente
3

Los diagramas UML son útiles para capturar y comunicar requisitos y garantizar que el sistema cumpla con esos requisitos. Se pueden utilizar de forma iterativa y durante varias etapas de planificación, diseño, desarrollo y prueba.

Del tema: Uso de modelos dentro del proceso de desarrollo en http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Un modelo puede ayudarlo a visualizar el mundo en el que funciona su sistema, aclarar las necesidades de los usuarios, definir la arquitectura de su sistema, analizar el código y asegurarse de que su código cumpla con los requisitos.

También es posible que desee leer mi respuesta a la siguiente publicación:

¿Cómo aprender “buen diseño / arquitectura de software”? en /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

- MSFT
fuente
3

Aunque esta discusión ha estado inactiva durante mucho tiempo, tengo un par de puntos -en mi opinión importantes- que agregar.

El código con errores es una cosa. Dejados a la deriva corriente abajo, los errores de diseño pueden volverse muy inflados y feos. UML, sin embargo, se autovalida. Con eso quiero decir que al permitirle explorar sus modelos en múltiples dimensiones, matemáticamente cerradas y de verificación mutua, genera un diseño robusto.

UML tiene otro aspecto importante: "habla" directamente con nuestra capacidad más fuerte, la de visualización. Si, por ejemplo, ITIL V3 (en el fondo bastante simple) se hubiera comunicado en forma de diagramas UML, podría haberse publicado en unas pocas docenas de folletos A3. En cambio, salió en varios tomos de proporciones verdaderamente bíblicas, generando toda una industria, costos impresionantes y un shock catatónico generalizado.

Matón
fuente
2
¿Ha leído el estándar UML? NO tiene ningún trasfondo matemático, e incluso tiene inconsistencias internas. También es muy difícil de entender: por ejemplo, los rectángulos redondeados se utilizan para dos cosas completamente diferentes (estados en máquinas de estado y acciones y actividades en diagramas de actividad). Es horrible.
vainolo
2

Veo diagramas de secuencia y diagramas de actividad que se utilizan con bastante frecuencia. Trabajo mucho con sistemas integrados y en "tiempo real" que interactúan con otros sistemas, y los diagramas de secuencia son muy útiles para visualizar todas las interacciones.

Me gusta hacer diagramas de casos de uso, pero no he conocido a demasiadas personas que piensen que son valiosas.

A menudo me he preguntado si Rational Rose es un buen ejemplo de los tipos de aplicaciones que se obtienen del diseño basado en modelos UML. Está hinchado, con errores, lento, feo, ...

Kristopher Johnson
fuente
2

Encontré que UML no es realmente útil para proyectos muy pequeños, pero es realmente adecuado para proyectos más grandes.

Básicamente, no importa lo que uses, solo debes tener en cuenta dos cosas:

  • Quieres algún tipo de planificación arquitectónica
  • Desea asegurarse de que todos los miembros del equipo estén utilizando la misma tecnología para la planificación del proyecto.

Entonces, UML es solo eso: un estándar sobre cómo planifica sus proyectos. Si contrata a nuevas personas, es más probable que conozca cualquier estándar existente, ya sea UML, Flowchard, Nassi-Schneiderman, lo que sea, en lugar de su material interno existente.

Usar UML para un solo desarrollador y / o un proyecto de software simple me parece una exageración, pero cuando trabajo en un equipo más grande, definitivamente querría algún estándar para el software de planificación.

Michael Stum
fuente
2

UML es útil, ¡sí! Los principales usos que le he dado fueron:

  • Lluvia de ideas sobre cómo debería funcionar una pieza de software. Facilita la comunicación de lo que está pensando.
  • Documentar la arquitectura de un sistema, sus patrones y las principales relaciones de sus clases. Ayuda cuando alguien ingresa a su equipo, cuando usted se va y quiere asegurarse de que su sucesor lo entienda, y cuando finalmente se olvida para qué demonios estaba destinada esa pequeña clase.
  • Documentar cualquier patrón arquitectónico que use en todos sus sistemas, por las mismas razones del punto anterior

Solo estoy en desacuerdo con Michael cuando dice que usar UML para un solo desarrollador y / o un proyecto de software simple le parece excesivo . Lo he usado en mis pequeños proyectos personales, y tenerlos documentados usando UML me ahorró mucho tiempo cuando volví a ellos siete meses después y había olvidado por completo cómo había construido y armado todas esas clases.

Mario Marinato -br-
fuente
2

Creo que puede haber una manera de utilizar casos de uso de peces, cometas y nivel del mar UML estilo Cockburn, como lo describe Fowler en su libro "UML Distilled". Mi idea era emplear casos de uso de Cockburn como ayuda para la legibilidad del código.

Así que hice un experimento y hay una publicación aquí al respecto con la etiqueta "UML" o "FOWLER". Fue una idea simple para c #. Encuentre una manera de incrustar casos de uso de Cockburn en los espacios de nombres de las construcciones de programación (como los espacios de nombres de clases y de clases internas o haciendo uso de los espacios de nombres para enumeraciones). Creo que esta podría ser una técnica viable y simple, pero todavía tengo preguntas y necesito que otros la revisen. Podría ser bueno para programas simples que necesitan un tipo de lenguaje específico de pseudo-dominio que puede existir justo en medio del código c # sin extensiones de lenguaje.

Por favor, consulte la publicación si está interesado. Vaya aquí .

engañadas por primas
fuente
2

Uno de los problemas que tengo con UML es la comprensibilidad de la especificación. Cuando trato de comprender realmente la semántica de un diagrama en particular, rápidamente me pierdo en el laberinto de metamodelos y metamodelos. Uno de los puntos de venta de UML es que es menos ambiguo que el lenguaje natural. Sin embargo, si dos o más ingenieros interpretan un diagrama de manera diferente, falla en la meta.

Además, he intentado hacer preguntas específicas sobre el documento de superestructura en varios foros de UML y a los miembros del propio OMG, con pocos o ningún resultado. No creo que la comunidad UML sea lo suficientemente madura como para sostenerse a sí misma.

Trento
fuente
2

Viniendo de un estudiante, encuentro que UML tiene muy poco uso. Me parece irónico que los PROGAMERS todavía tengan que desarrollar un programa que genere automáticamente las cosas que usted ha dicho que son necesarias. Sería extremadamente simple diseñar una función en Visual Studio que pudiera extraer partes de los datos, buscar definiciones y respuestas de productos suficientes para que cualquiera pudiera verla, grande o pequeña, y comprender el programa. Esto también lo mantendría actualizado porque tomaría la información directamente del código para producir la información.

Miguel
fuente
¡No es así de fácil! Si usa ingeniería inversa para extraer un modelo UML de código real, tiende a terminar con tantos detalles en su modelo UML que es inútil. No hay duda de que esto está siendo perseguido por los investigadores, pero no es un problema fácil de resolver.
ComDubh
2

UML se usa tan pronto como representas una clase con sus campos y métodos, aunque es solo una especie de diagrama UML.

El problema con UML es que el libro de los fundadores es demasiado vago.

UML es solo un lenguaje, no es realmente un método.

En cuanto a mí, realmente me molesta la falta de esquema UML para proyectos de código abierto. Tome algo como Wordpress, solo tiene un esquema de base de datos, nada más. Tienes que deambular por la API del Codex para tratar de obtener una imagen completa.

programador
fuente
1

UML tiene su lugar. Se vuelve cada vez más importante a medida que crece el tamaño del proyecto. Si tiene un proyecto de larga duración, lo mejor es documentar todo en UML.

Vaibhav
fuente
O al menos las cuestiones clave de diseño.
Silvercode
1

UML parece bueno para proyectos grandes con grandes equipos de personas. Sin embargo, he trabajado en equipos pequeños donde la comunicación es mejor.

Sin embargo, usar diagramas tipo UML es bueno, especialmente en la etapa de planificación. Tiendo a pensar en código, así que me resulta difícil escribir especificaciones grandes. Prefiero escribir las entradas y salidas y dejar que los desarrolladores diseñen el bit en el medio.

graham.reeds
fuente
1
También en proyectos un poco más pequeños es frustrante trabajar comunicando en mi opinión. Si tiene que preguntar y contar todo el tiempo muchas cosas, interrumpe el trabajo y no se producen documentos. En cambio, los principios clave de diseño deben documentarse y modelarse.
Silvercode
1

Creo que UML es útil solo por el hecho de que hace que la gente piense en las relaciones entre sus clases. Es un buen punto de partida para empezar a pensar en este tipo de relaciones, pero definitivamente no es una solución para todos.

Mi creencia es que el uso de UML es subjetivo a la situación en la que está trabajando el equipo de desarrollo.

Adam Mika
fuente
0

En mi experiencia:

La capacidad de crear y comunicar diagramas de código significativos es una habilidad necesaria para cualquier ingeniero de software que esté desarrollando un código nuevo o intentando comprender el código existente.

Conocer los detalles de UML (cuándo usar una línea discontinua o un punto final de círculo) no es tan necesario, pero es bueno tenerlo.

David Koelle
fuente
0

UML es útil de dos formas:

  • Lado técnico: mucha gente (gerente y algún analista funcional) piensa que UML es una característica de lujo porque el código es la documentación: comienzas a codificar, después de depurar y corregir . La sincronización de los diagramas UML con el código y los análisis te obligan a comprender bien las solicitudes del cliente;

  • Lado de administración: los diagramas UMl son un espejo de los requisitos del cliente que es inexacto: si codifica sin UML, tal vez pueda encontrar un error en los requisitos después de muchas horas de trabajo. Los diagramas UML te permiten encontrar los posibles puntos controvertidos y resolverlos antes de que la codificación => ayude a tu planificación.

Generalmente, todos los proyectos sin diagramas UML tienen un análisis superficial o tienen un tamaño reducido.

si estás en el grupo de LinkedIn SYSTEMS ENGINEERS , mira mi discusión anterior .

alepuzio
fuente
-1

Al final, UML solo existe gracias a RUP. ¿Necesitamos UML o cualquiera de sus elementos relacionados para usar Java / .Net? La respuesta práctica es que tienen su propia documentación (javadoc, etc.) que es suficiente y nos permite hacer nuestro trabajo.

UML no gracias.

mP.
fuente
RUP se trata de gestión de procesos, UML se trata de lenguaje. UML es útil cuando se trata con mucha gente y se necesita un lenguaje común.
programmernovice
1
¿Alguna vez has oído hablar de los susurradores chinos? Cuanto más se traduce de una forma a otra, el significado, la diferencia y el error se infiltran. Si UML es tan bueno, ¿por qué Microsoft, Sun, Google no incluyen UML en los detalles de sus productos? Te resultará difícil encontrar alguno. ¿Qué pasó con las herramientas? ¿Herramientas bidireccionales hacia adelante / hacia atrás? No existen porque esa moda murió por falta de mérito.
mP.
-1

UML es definitivamente útil al igual que junit es esencial. Todo depende de cómo vendas la idea. Su programa funcionará sin UML del mismo modo que funcionaría sin pruebas unitarias. Dicho esto, debe crear do UML ya que está conectado a su código, es decir, cuando actualiza los diagramas UML, actualiza su código, o cuando actualiza su código, genera automáticamente el UML. No lo haga por el simple hecho de hacerlo.

fastcodejava
fuente
-2

UML definitivamente tiene su lugar en la industria. Imagine que está creando software para aviones Boing o algún otro sistema complejo. UML y RUP serían de gran ayuda aquí.

EdinD
fuente
-3

UML es solo uno de los métodos de comunicación entre las personas. La pizarra es mejor.

popopome
fuente