Delphius,
En primer lugar gracias por tus comentarios, se ve que eres una persona muy particular y compleja en tus opiniones según he podido ver en otros post (Propios y de Terceros) y dada la naturaleza del tema comprendo tu posición, pero el punto aquí no es hacer un debate exhaustivo sobre los paradigmas sobre los que se basan las metodologías de análisis estructurado y OO, es simplemente poder colaborar con alguien que necesita un punto de partida para su proyecto, no obstante tratare de explicarme mas detalladamente.
En la década de los 90 se crearon alrededor de 50 metodologías orientadas a objeto, cada una con su orientación, pero gracias a la unificación que propuso UML se llego a un lenguaje de modelado visual que permite gran expresividad semántica gracias a la naturaleza de sus diagramas, la experiencia acumulada hasta el momento en A&D/OO y la necesidad de una herramienta que no limitara el análisis sino que lo apoyara y extendiera si era necesario según cada contexto particular.
UML no pretende ser una metodología, tampoco considera que sus diagramas modelen en su totalidad todas los escenarios, es por ello que existe un apartado de mecanismo de extensión en el cual por medio de restricciones, valores etiquetados y estereotipos se puede extender el modelo visual para que se adapte mejor a un contexto particular, es decir: UML es extensible, los DFD y DER no pueden usar a UML, pero UML si puede usar a estos si se considera apropiado y de valor semántico con las adaptaciones correspondientes a elementos de UML.
El hacer un paralelismo entre procesos en un DFD y entidades en un DER con clases no esta lejos de la realidad, al final una clase es un conjunto de métodos y atributos que modelan por abstracción procesos y datos asociados en el mundo real de forma unisona por medio de un paradigma OO y UML permite por medio de los mecanismos de extensión, en este caso los estereotipos, hacer uso de nuevos elementos visuales con la salvedad de que estos nuevos elementos no forman parte del estándar UML y por consiguiente pueden prestarse a confusión y polémicas, teniendo sentido solamente dentro del contexto particular en que se los definió, por lo cual entiendo tu posición pero es algo que se puede usar si se considera que aporta mayor expresividad semántica al análisis, no solo crear tus equivalentes de DFD y DER en UML basados en clases, sino crear cualquier elemento visual que se requiera con las restricciones mencionadas anteriormente.
¿Hace falta en UML crear un equivalente basados en clases de los DFD y DER? : A UML no le hace falta pero desde un punto de vista estrictamente comunicacional y académico que permita plasmar dichos elementos de análisis como punto de partida y complemento del estándar UML es factible hacerlo, sirve de punto de partida para el análisis y permite aclarar ideas si el área de experticia es el análisis estructurado. Tener múltiples perspectivas ayudan y facilitan el modelamiento de un sistema, esa es la idea detrás de los estereotipos de UML y de sus mecanismos de extensión.
La idea de UML es hacer el análisis y diseño orientado a objeto más fácil, sin limitaciones de metodología, adaptable a cualquier metodología y extensible para un mejor aprovechamiento de este, no lo contrario que fue lo que ocurrió en los 90 en el cual se dio un fuerte debate sobre el tema, pero gracias a estas polémicas surgió UML como un estándar de modelamiento OO vigente hasta la fecha.
Otros puntos:
1- Los Casos de Uso fueron creados por Ivar Jacobson en 1986 y usados por primera vez en 1992 en la metodología de diseño orientado a objetos OOSE (Object-Oriented Software Engineering) y posteriormente integrada a UML y RUP, aunque su uso nació dentro del ámbito OO se puede implementar en otras áreas como una forma de modelar procesos y eso es lo grandioso de UML y sus elementos: Se pueden usar como un lenguaje de modelamiento visual en otras áreas diferentes a la computación, lo cual muestra su flexibilidad y robustez semántica, pero lo cierto es que se usa principalmente el A&D/OO por ser algo propio de esta área.
2- Los Diagramas de Comunicación de UML 2.0 son una versión simplificada de los Diagramas de Colaboración de UML 1.X, pero en la mayoría de los libros se refieren a estos como Diagramas de Colaboración, la idea es usar la versión 2.X o posteriores.
3- ¿Por que recomendar el libro "Aprendiendo UML en 24 Horas" y no otro más complejo?: El conocimiento se construye por capas y este libro permite una orientación inicial al tema y sirve de base para posteriores libros como por ejemplo "El Lenguaje Unificado de Modelado, Manual de Referencia" escrito por los autores de UML o cualquier otro que el lector decida, al final los libros son puntos de partida hasta que nos formemos un criterio propio, cada quien encoje con que libro iniciar el camino, la simplicidad es la base de la complejidad.
4- Con respecto a las Bibliotecas, Internet y la Red P2P Emule creo que pueden convivir perfectamente, al final es muy probable que todos los libros sean digitales y las bibliotecas virtuales sean la norma en lugar de la excepción por muchas razones que pienso son conocidas por las mayoría de las personas que usan una computadora asiduamente.
5- ¿El usar términos en ingles y en español en un mundo tan globalizado, signado por la tecnología y la internet dentro del ámbito de la computación es algo reprochable?, honestamente no lo creo pero respecto las opiniones contrarias.
6- ¿Que si falto explicar esto o aquello sobre UML?, no es un tratado sobre UML es solo una orientación inicial a un problema real.
7- Creo firmemente que un rasgo notable de la computación es su flexibilidad y adaptabilidad a cualquier situación en la búsqueda de soluciones innovadoras y no la simple repetición de textos y métodos, creo que cada situación es única y por tanto una oportunidad para aprender y desarrollar lo aprendido, no veo por que esta situación sea diferente.
Pensamientos finales:
Creo que todo el problema se origino por una incorrecta redacción del punto uno el cual podemos reescribir como: "1- Es conveniente que empieces a modelar tu proyecto usando Casos de Uso de lo general a lo particular haciendo un paralelismo con los DFDs, (DFD-0) -> Caso General) y (DFD-1, DFD-2, ... , DFD-n) -> Casos particulares, pero tomando en cuenta que pertenecen a paradigmas diferentes y es válido solo como punto inicial del análisis."
Otro punto de error fue no explicar mas extensamente los estereotipos en UML pero creo que la idea es dar una guía general en la mayoría de los casos que sirva de base a la solución del problema planteado en el post y recomendar otros links y libros que complementen la respuesta.
Este tipo de controversias las he visto muchas veces en tesis de grado de pregrado y postgrado y generalmente se deben a pre concepciones muy arraigadas sobre un tema o a la falta de una mejor redacción por parte del expositor. Creo firmemente en el conocimiento, pero también en la evolución del mismo con fines prácticos y no solo teóricos, la teoría es solo el comienzo pero lo practico es y debe ser el final dentro de una concepción holística del tema.
Admito que la extensión de UML con estereotipos basados en DFD y DER es algo polémico y controversial para algunos, pero esto lo he probado en diversos ámbitos con resultados favorables a efectos de comunicación de nuevos conceptos y punto de partida de análisis mas detallados con los elementos propios del UML, esa es la idea detrás de todo este tema : Un punto inicial de transición del modelo estructurado al modelo OO por medio de UML.
Para finalizar creo que debemos respetar las opiniones de todos, manifestar nuestro desacuerdo de forma profesional, educada y con argumentos y tratar de mantener un clima de cordialidad y ayuda a todas las personas que usen este medio, no creo que una discusión peyorativa y purista ayude en nada a resolver los problemas planteados en el Club Delphi, al final las personas que viene a este foro buscan soluciones practicas a problemas reales y no simple disertación teórica que aunque necesaria en su momento, no es el objetivo final.
Espero sea útil
Nelson.