[[Delphius]]

Conclusión has intentado mezclar cosas que no van. ¿Para que mencionar en una misma oración términos como herencia, polimorfismo, DFD y DER? ¡Son agua y aceite! ¿Donde quedó la explicación del estereotipo en esto? ¡Dime!

Mi parecer: intentaste dar una forma de presentar y combinar ambos temas y no encontraste la forma y mandaste lo que te salió del momento. Resultado: ¡tutti frutti! Aquí hace calor y admito que me encanta la ensalada de frutas, pero prefiero no comer demasiada porque me provoca diarrea... como la diarrea mental que largarse en ese párrafo.

En tu ampliación a las explicaciones arreglaste mejor tus palabras. Pero te olvidas de algo fundamental: no existe paralelismo entre un DFD/DER con Diagrama de Clases. Como he expresado antes, son perpendiculares, hay un ángulo conceptual de 90º... Se dice que allá en el infinito las paralelas se cruzan. La conversión no es directa.
Y como tu indicas que la introducción de estereotipos para conseguir semejante cosa es ya fuera de estándar, entonces con más razón es un motivo muy riesgoso de presentarlo ya que requiere de una mayor preparación y se reduce el potencial de comunicar ideas y que otros las entiendan. No todos están al tanto de los estereotipos... y peor se pone si justamente el estereotipo para conseguir DFD en UML es uno definido por el usuario.

Si David lo utilizase ¿cuál será la probabilidad de que se lo acepten y le den el visto bueno? Para cátedra, ¡deja las cosas en el estándar! Los "experimentos fuera "del libro" déjalos para después, para cuando tenga tiempo, ganas y pueda profundizarse.
Ese es el motivo por el cual yo trato de mantener a los diagramas limpio y de usar las cosas para los que fueron concebidas y el porqué de toda esta lección: Mantenerme lo más simple y apegado al estándar, y aprovechar cada cosa con lo suyo:
UML -> apoyo a mis A/D OO
Diagramas de flujo (que no el diagrama de flujo de datos, o DFD) -> algoritmos
DER -> para mis DBs
Análisis Estructurado -> para mis A/D estructurados

Estas ármas ya son estándares, y uno puede tomarlas sin problemas. Si alguien más las lee podrá entenderme. Si yo condimentara como tu a los diagramas con el estereotipo estructurado (y que te invito a que nos muestres como se ve; en parte por curisoso) me expongo a reducir ese poder que posee el UML que es la de comunicación, y en el peor caso que oscurezca demasiado las cosas al punto en que termine siendo peor la cura que la enfermedad.

Ya lo he dicho: los estereotipos son un arma de doble filo. UML ofrece flexibilidad y muchas cosas se las puede dar de forma simple, sin estar rellenando todo. Ese poder es fantástico, porque uno puede regular la cantidad de cosas a mostrar sin perder el hilo; pero también se vuelve en contra cuando para ilustrar una idea debe meterle más cosas que las por defecto y las opcionales que ofrece a disposición el estándar.
Existe un equilibrio, ni mucho ni poco. Dime ahora ¿Tu que lado de la balanza prefieres?

Empezado por nlsgarcia

La idea era dar una referencia teórica que permita establecer el paralelismo entre UML y el Análisis Estructurado basado en DFDs y DER, pero por supuesto depende del que lo lee investigar un poco sobre el tema, en este caso es un punto de partida práctico no la solución final y mucho menos ideal.

Si tu idea era dar ese supuesto paralelismo, ¿donde está? Porque en ningún momento te deteniste a explicar en como llevarlo. Dices que con estereotipos, ¡pero al menos debes dar una pista de como proceder!
Cuando un profesor corrige una prueba no sólo debe decir la respuesta es la C, sino agarrar una tiza y explicarles al menos medianamente en cómo se podría llegar a ese resultado. Seguramente, alguna vez, tu has pedido a tus profes que se detenga a explicar algo o que te evacue una duda. ¿Porqué no hacer ese mismo ejemplo con David?

Si tan seguro estás de que la respuesta está en UML estereotipado con estructurado. ¡Demuéstralo! ¡Algo breve!

Empezado por nlsgarcia

Creo que es una gran virtud del lenguaje que expresa su gran capacidad de adaptabilidad y flexibilidad a diversos escenarios.

En eso coincidimos. Pero el punto es que no por mucha flexibilidad quiere decir que se pueda jugar con ella. No abuses.

Empezado por nlsgarcia

Solo explique el origen de los Casos de Uso y su relación con el A&D/OO, los Casos de Uso son fundamentales en UML y RUP y una herramienta muy poderosa para el modelado OO.

Error. Los casos de uso no son fundamentales para UML, de hecho todo diagrama de UML es independiente de otro, no existe una dependencia... nada te obliga a hacer todos o algunos; uno elige que y cuando hacerlo. UML es muy libre e independiente de paradigmas de desarrollo y/o metodologías. No hay un orden establecido (allí es donde SI se meten los modelos o procesos de desarrollo y metodologías).
Lo que dices es justamente el error que veo en muchos: creen que todo comienza en los casos de uso y que sin ellos no se puede avanzar. Para hacer diagramas UML se puede partir de cero, con cualquiera; lo lógico es empezar con el diagrama que más te ofrezca claridad para conducir las ideas, aclarar las dudas y bajarlas a tierra. Si es el diagrama de clases, perfecto; si son los DS (Diagrama de Secuencia) también, si es el de Paquetes... ¡también!
Este error tiene un trasfondo en una mala enseñanza de Ingeniería de Software y una concidencia histórica mal difundida. Para RUP si es fundamental, porque así lo dispuso. Esto es más de "metodología" que una necesidad o que en verdad existiera algún orden de como hacer las cosas.
Si sigues otro modelo o proceso de desarrollo que no sea RUP o algún otro de la línea UP (aclaro por las dudas, y para quien no sepa: RUP no es el único modelo UP) te darás cuenta de lo que digo: que RUP proponga y parta desde los casos de uso no quiere decir que necesariamente deba ser así siempre y para otros modelos (incluso uno propio).
Comparto contigo que los CUs son una herramienta poderosa, ¡pero no necesariamente son indispensables! ¡Saca eso de la cabeza!